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Foreword 



The E-smart 2001 international conference on research in smart cards was held 
in Cannes, France on 19-21 September. The conference was jointly organized 
by the Java Card Forum, Eurosmart and INRIA, and received helpful financial 
support from the Conseil Regional Provence- Alpes- Cote d’Azur. 

The intention with E-smart is to provide a forum for discussion and exchange 
of results on smart card development, security, and applications. This year’s pro- 
gram was established by an international program committee that examined 38 
papers submitted and selected 20 of these for presentation. The list of topics of 
this year’s presentations includes biometrics, cryptography and electronic signa- 
tures on smart cards, hardware and software solution for smart card security, 
formal methods for smart card evaluation and certification, architectures for 
multi- applications and secure open platforms, middleware for smart cards and 
novel applications of smart cards. The conference also featured an invited talk 
by Simon Moore from the University of Cambridge. 



Isabelle Attali 
Thomas Jensen 
E-smart 2001 program committee co-chairs. 




Organization 



Program Committee 

Isabelle Attali, INRIA 

Dominique Bolignano, Trusted Logic 

Bertraud du Castel, Schlumberger 

Wolfgaug Efiiug, Giesecke & Devrieut 

Christiau Goire, Bull GPS 

Pieter Hart el, Uuiversity of Tweute 

Peter Houeymau, Uuiversity of Michigau 

Thomas Jeuseu, IRISA / GNRS 

Pierre Paradiuas, Gemplus 

Joachim Posegga, SAP AG 

Peter Ryau, GERT 

Jeau-Paul Thomassou, ST Microelectrouics 
Yasuyoshi Uemura, EGSEG 



Thauks are due to the followiug people for their help with the refereeiug of 
papers: Thomas Geuet, Valerie Viet Triem Toug, Stefau Eriedich, Harald Vogt, 
Jaap-Heuk Hoepmau, Neil Heudersou, Adam Eield, aud Jordau Ghoug. 




Table of Contents 



Invited Talk 

Protecting Consumer Security Devices (The Next 10 Years) 1 

Simon Moore 

Contributed Papers 

Jakarta: A Toolset for Reasoning about JavaCard 2 

G. Barthe, G. Dufay, M. Huisman, and S. Melo de Sousa 

Mechanising a Protocol for Smart Cards 19 

Giampaolo Bella 

JCCM: Flexible Certificates for Smartcards with Java Card 34 

Geleste Gampo, Andres Marm, Arturo Gareia, Ignaeio Diaz, 

Peter T. Breuer, Garlos Delgado, and Garlos Gareia 

Context Inference for Static Analysis of Java Card Object Sharing 43 

Denis Garomel, Ludovie Henrio, and Bernard Serpette 

Automated Test and Oracle Generation for Smart-Card Applications 58 

Dunean Glarke, Thierry Jeron, Vlad Rusu, and Elena Zinovieva 

An Internet Authorization Scheme 

Using Smart-Card-Based Security Kernels 71 

Yves Deswarte, Noreddine Ahghour, Vineent Nieomette, 
and David Powell 

Turning Multi-applications Smart Cards Services Available 
from Anywhere at Anytime: A SOAP/MOM Approach 

in the Context of Java Cards 83 

Didier Donsez, Sebastien Jean, Sylvain Leeomte, and Olivier Thomas 

An Operational Semantics of the Java Card Firewall 95 

Mare Eluard, Thomas Jensen, and Ewen Denne 

CardS4: Modal Theorem Proving on Java Smartcards Ill 

Rajeev Prabhakar Gore and Phuong The Nguyen 

iButton Enrolment and Verification Requirements 

for the Pressure Sequence Smartcard Biometric 124 

Neil J. Henderson, Neil M. White, and Pieter H. Hartel 

SIMspeak - Towards an Open and Secure Application Platform 

for GSM SIMs 135 

Roger Kehr and Hendrik Mieves 




VIII Table of Contents 



On- Card Bytecode Verification for Java Card 150 

Xavier Leroy 

Towards a Full Formal Specification of the JavaCard API 165 

Hans Meijer and Erik Poll 

Protection Profiles and Generic Security Targets 

for Smart Cards as Secure Signature Creation Devices - 

Existing Solutions for the Payment Sector 179 

Gisela Meister and Miehael Vogel 

A Flexible Invocation Framework for Java Card 188 

Miehael Montgomery and Ksheerabdhi Krishna 

ElectroMagnetic Analysis (EM A): 

Measures and Counter-Measures for Smart Cards 200 

Jean-Jaeques Quisquater and David Samyde 

Information Leakage Attacks against Smart Card Implementations 

of the Elliptic Curve Digital Signature Algorithm 211 

Tanja Romer and Jean- Pierre Seifert 

Use of Biometrics for User Verification 

in Electronic Signature Smartcards 220 

Bruno Struif 

Programming Internet Smartcard with XML Scripts 228 

Paseal Urien 

Public-Key-Based High-Speed Payment (Electronic Money) System 

Using Contact-Less Smart Cards 242 

Hideo Yamamoto, Tetsutaro Kobayashi, Masahiro Morita, 
and Ryuji Yamada 



Author Index 



255 




Protecting Consumer Security Devices 

The Next 10 Years 



Simon Moore 

University of Cambridge, Computer Laboratory 
Simon . MooreQcl . cam .ac.uk 



Extended Abstract 

In this talk, I will speculate about the likely near-term and medium-term scien- 
tific developments in the protection of low cost consumer security devices. 

The mass adoption of embedded computing devices (mobile phones, PDAs, 
smartcards, etc) is moving us rapidly into the ubiquitous computing age. If 
these devices are too be a boon rather than a bane then robustness is going to 
be increasingly important. Security will be increasingly important, not only for 
traditional roles like payment mechanisms and access control, but also for peer 
to peer transactions and new business structures. 

Peer to peer transactions between ones own devices need to be transparent 
and robust. Transactions between your devices and others needs more control to 
ensure that communication only takes place at your convenience. This requires 
robust authentication mechanisms (e.g., the Resurrecting Duckling Protocol) 
coupled with a simple, elegant and intuitive user interface. 

Novel business models arise from low cost embedded security devices. For 
example, per use leasing arrangements in a variety of guises, e.g. washing ma- 
chines and other home appliances, software, videos, pay TV, public bicycles and 
car pools. 

In practice we have seen how invasive attacks (reverse engineering) , litigation 
attacks (abusing the legal discovery process) and business process failures have 
resulted in design discovery. Thus, inline with Kerckhoffs’ principle, the security 
of a consumer security devices should only he in keeping the key secret. 

Extracting a key must be kept economically unattractive. Invasive attacks 
(probing the chip) to obtain key information are simpler than full reverse engi- 
neering attacks. These attacks tend to leave tamper evidence which limits their 
scope for some applications, but is a significant risk in any environment where 
identical copies of the same security device are useful (e.g. current PayTV sys- 
tems). 

Non-invasive attacks, on the other hand, extract information by analysing 
side channel information like electromagnetic emissions and power consumption, 
which leave little tamper evidence. As part of the GSCard European project 
(1ST- 1999- 135 15) we have been advancing attack techniques to better under- 
stand threat models. This knowledge is being used to guide the development of 
novel circuit and software techniques to make non-invasive attacks more difficult. 

^ see http://www.cl.cam.ac.uk/users/rjal4/duckling.html 

I. Attali and T. Jensen (Eds.): E-smart 2001, LNCS 2140, pp. 1-1, 2001. 

© Springer- Verlag Berlin Heidelberg 2001 



Jakarta: 

A Toolset for Reasoning about JavaCard 
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1 Introduction 

JavaGard [22] is a dialect of Java that enables Java technology to run on new 
generation smart cards and other devices with limited memory. As JavaGard 
is becoming increasingly popular, there has been a strong interest, both from 
academics and industrials, to reason formally about the JavaGard platform. 

This paper reports on preliminary results with Jakarta, a toolset for speci- 
fying and reasoning about the JavaGard platform. The main ingredients of the 
toolset are: 

1. the Jakarta Specification Language (JSL), a front-end for producing highly 
readable executable specifications; 

2. the Jakarta Transformation Kit (JTK), a program to manipulate and trans- 
form JSL specifications; 

3. the Jakarta Prover Interface (JPI), a compiler that translates JSL specifica- 
tions into proof assistants; 

4. the Jakarta Automation Kit (JAK), a toolset to support reasoning about 
executable specifications within proof assistants. 

The main slogan behind Jakarta’s design is that: 

a dedicated specification language is not only useful to achieve readable 
executable specifications that are easy to animate and debug, but it also 
can have a dramatic positive impact on formal verification. 

To support this slogan, the benefits of this approach over using a proof assistant 
directly, as done in our previous work [3], are illustrated. 

1.1 Background 

Formal Methods for Smart Cards With the increasing popularity of Java 
and JavaGard, there has been a spate of efforts, both by academics and in- 
dustrials, to develop formal models for the Java and JavaGard platforms, see 
e.g. [3,6,9,16,20,21,27,28,31]. 

* On leave from University of Beira Interior-Portugal, and partially supported by the 
Portuguese research grant sfrh/bd/790/2000. 
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In earlier work [3], we report on CertiCartes, a formalisation in Coq [2] of a 
large part of the JavaCard platform. With over 15,000 lines of Coq scripts, our 
formalisation constitutes to date the most in-depth machine- checked account of 
the JavaCard platform. CertiCartes contains a formal executable specification 
of the (defensive) JavaCard Virtual Machine JCVM, and a formal executable 
specification of the JavaCard ByteCode Verifier BCV, with its correctness proof. 

This BCV has been constructed in a systematic way, by abstraction, from the 
specification of the virtual machine. First an abstract virtual machine has been 
constructed, describing the computational behaviour of bytecode verification. 
This abstract virtual machine is obtained systematically from the concrete vir- 
tual machine by defining a notion of abstract state, a function a mapping states 
to abstract states, and by adapting the semantics of each instruction to abstract 
states. It has been shown that the abstraction function “commutes with” execu- 
tion (up to subtyping). Next, a data flow analyser has been build, that computes 
from the abstract virtual machine the BCV as a predicate on programs, and it 
has been shown that this data flow analyser terminates. 

The methodology followed to specify and prove the correctness of the BCV 
is very appealing, in that it provides a systematic approach to the design and 
validation of static analyses for JCVM programs. Indeed, we are keen on applying 
a similar methodology for analysing object initialisation, information flow etc. 
However, our experiences with proving the correctness of the BCV suggest that 
Coq and more generally current proof assistants are not completely adapted for 
such endeavours: the specification of the virtual machine is cluttered, proofs are 
tedious and the level of automation is low. 



Prototyping Environments and Proof Assistants Many of these difflcul- 
ties can be solved by using a dedicated prototyping environment that supports 
some/most administrative aspects of formal semantics. A number of tools have 
been designed for this purpose, including ASF-hSDF [15], Centaur [10], Letos [18] 
and RML [30]. These tools are rather diverse in their design and functionalities, 
but they all provide: 

— a readable format for giving a formal semantics to programming languages; 

— support to execute the semantics, which in particular allows to check that 
the semantics reflects the intended behaviour of the language. 

However, prototyping environments lack functionalities to reason formally about 
the semantics, in contrast to proof assistants such as Coq [2], Isabelle [29] or 
PVS [32], which feature advanced type systems that support precise specifica- 
tions and sophisticated reasoning. 

In order to deal with real-size programming languages, there is thus con- 
siderable interest in integrating prototyping environments and proof assistants. 
Despite preliminary work in this direction, see Section 6.1, we still lack a tool 
that reflects manipulations in the specification environment of prototyping sys- 
tems directly into the reasoning environment of proof assistants. 
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1.2 This Paper 

The Jakarta toolset is an attempt to overcome the difficulties encountered in 
CertiCartes through the design of a suitable bridge between a prototyping envi- 
ronment and a proof assistant. The main goal of Jakarta is to provide support for 
refinements and abstraetions. Through JTK, Jakarta offers interactive support 
to define a function f \ a' ^ o' from a previously defined function f : a ^ a. 
The process, which operates at the level of rewrite rules, can be used if (1) cr' is 
less specific than cr, in which case the process requires an abstraction function 
cr : cr cr' or; (2) cr' is more precise than cr, in which case the process requires 
a refinement function a \ a' a. Currently, Jakarta supports abstractions, re- 
finements will be future work. In the context of reasoning about the JavaCard 
platform, abstraction is useful to construct e.g. the BCV from the JCVM. 

To improve the support for refinement and abstractions, the Jakarta toolset 
has been designed with the following objectives. 

— Clarity of speeifieations: Jakarta specifications are written in JSL, a front- 
end for producing executable specifications. The JSL language is a first-order, 
polymorphically typed system which features polymorphic datatype decla- 
rations and function definitions by conditional rewrite rules. The formalism 
is reasonably neutral and leads to specifications that are easy to read, extend 
and manipulate. 

— Tool independenee: the JSL specification language is minimal and JSL spec- 
ifications are thus easy to embed into other formalisms. We have developed 
a compiler JPI that translates JSL specifications into an intermediate repre- 
sentation language JIR, and then from JIR to proof assistants, prototyping 
environments and programming languages. Due to the limited format of 
JSL rewrite rules, JSL specifications are close to their compiled counterpart, 
which ensures that what you specify (in JSL) is what you reason about 
{e.g. in Coq). 

— Proof automation: the limited format of JSL makes it possible to develop 
customised tools to reason about JSL specifications. For example, JAK gen- 
erates for every JSL function / an inversion principle, which is based on an 
analysis of JSL rewrite rules. Given a predicate 0, relating /’s input to its 
output, an application of the inversion principle reduces the task of proving 
\/x : a. (j) {x, f x) to several simpler subtasks. This has shown particularly 
useful in proving the correctness of the BCV. 

A further pay-off of the independence of proof assistants is that JSL supports 
partial funetions, such as the head of a list. While such partial functions can- 
not be compiled into the specification language of proof assistants, they can be 
transformed automatically via JTK into a specification based on total functions, 
which can be translated to proof assistants. 

The Jakarta toolset is implemented in Objective Caml [24]. Figure 1 sum- 
marises its basic architecture. In its standard use, the Jakarta toolset takes JSL 
specifications as input. The Jakarta Transformation Kit (JTK) can transform a 
JSL specification into a more abstract one. The Jakarta Prover Interface (JPI) 
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translates JSL specifications into a format that is readable for e.g. a proof as- 
sistant or a prototyping environment, via an intermediate language (JIR). The 
Jakarta Automation Kit (JAK) generates appropriate proof strategies in the 
proof assistant, based on the JSL specification. 



1.3 Organisation of the Paper 

The remaining of the paper is organised as follows: Section 2 introduces JSL and 
presents the specification of the JCVM in JSL. Section 3 gives an overview of 
JPI, and Section 4 describes the functionalities that will be provided by the JTK. 
Section 5 is concerned with JAK, and discusses its usefulness in establishing the 
correctness of the BCV. Section 6 concludes with related work and directions 
for future research. 

2 The Jakarta Specification Language 

Jakarta’s input language JSL is a minimal language (Figure 2 gives a flavour of 
JSL, below a larger example of a JSL specification is discussed): 

— JSL types are first-order polymorphic types; 

— JSL expressions are standard first-order algebraic terms; 

— JSL functions are defined by conditional rewrite rules. 

Having a restricted framework is useful to abstract or refine specifications and 
to compile and reason about them in proof assistants. 



JSL Expressions JSL expressions are first-order terms built from variables 
and constant symbols. The latter are either constructor symbols, introduced by 
datatype declarations, or defined symbols, introduced by function definitions. 
Formally, expressions are defined as follows. 
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data nat = Zero | Succ of nat . 

function plus : nat -> nat -> nat := 
begin 

m -> Zero => plus m n -> n; 
m -> Succ y => plus m n -> Succ (plus y n) ; 
end. 



Fig. 2. Example of JSL specification 



Definition 1. 

— A signature consists of a set C of constructor symbols^ V of defined 
symbols and an arity function ar : (CUV) ^ N. 

— Let E he a signature and let V be a fixed set of variables. The set E of 
expressions ( over E) is defined by the abstract syntax: 

£.-\;\S==S\cS\f S 

where c ranges over C, f ranges over V, and in the last two clauses it is 
assumed that S is of length ar(c) and ar(/) respectively. 

For every f E V, we let £d{f) C £ be the set of expressions with head 
symbol f, i.e. we let £d{f) = {f t \ t ^ £}. Moreover, we let £d denote 
VU(U/e^, Saif)). 

JSL provides concrete syntax for records. Internally they are represented as 
inductive datatypes with a single constructors, as is done in Coq, thus no abstract 
syntax has to be defined for them explicitly. 

We assume the reader to be familiar with standard notions such as subterms, 
occurrences, substitutions, and the associated notations, see e.g. [23]. 



JSL Rules Defined function symbols are specified by rewrite rules. In term 
rewriting jargon, our formalism is a restriction of constructor-based oriented 
conditional rewriting with extra variables! More precisely, the semantics of a 
defined function symbol is described by a set of oriented conditional rewrite 
rules of the form 

... ,ln^rn=^g^d 

The novelty of JSL rules is that we require that the right-hand sides of conditions 
are patterns with fresh variables. This restriction yields a formalism that is 
closely related to pattern-matching. 

Definition 2 (Rewrite rule). Let E be a signature. 
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— The set V of patterns is defined by the abstraet syntax 

V:=V\cV 

where in the seeond elause it is assumed that patterns have pairwise disjoint 
sets of variables (in other words, patterns are required to be linear). 

— An /-rewrite rule is a eompound R of the form 

h^ri, ... , In ^ rn ^ g ^ d 



where: 

• r\ ... rn ^ V , h ... In ^ £d cind d G E; 

• g = f X where x G V are pairwise distinet; 

• for I < i < n, var(/^) C var(^) U var(ri) U ... U var(r^_i); 

• for I < i, j < n with i 7^ j, var(ri) D var(^) = 0 and var(r^) H var(rj) = 0; 

• var(d) C var(5f) U var(ri) U ... Uvar(rn). 

— The domain dom(i7) of a rewrite rule R is defined as 

var(^) U U var(ri) 

l<i<n 

— The set of rewrite rules is denoted by IZ, so 1 Z C List {Ed x V) X (fdXf). 

— The set of rewrite systems is denoted by R, so R = PowFin IZ. 

JSL rewrite rules have a restricted format, but the Jakarta toolset provides 
some syntactic sugar, e.g. to allow more complex structures in the rewrite rules, 
and to provide means to define constants and records. For example, record f 00 
= {one : nat ; two : bool;} defines a record with two entries, labelled one 
and two. An instance in this record type is created as {one = Zero; two = 
False}. Entries in the record can be accessed using the dot notation, e.g. x. one 
returns the value of the one entry in the record x, and updated using the with 
notation, e.g. x with {two = True} replaces the two entry in the record x with 
the value True. Rewrite rules using this syntactic sugar internally are trans- 
formed into pure JSL rules. 



JSL Execution Model As pointed out by [5], the notion of rewriting for 
conditional rules is defined inductively. Figure 3 illustrates the execution model 
for JSL rules. Formally this is defined as follows. 

Definition 3. Let IZ be a set of rewrite rules. An expression s IZ-rewrites to t, 
written s L 'If there exists a rule R e 7Z 

... fin^'^n=^g^d 

a position p of s and a substitution 0 with domain 6om{R) sueh that: 

— s \p= Og and t = s[p ^ Od]; 

— for 1 < i < n, Oli Ori; 

where 'Is the reflexive-transitive elosure of 
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n -> Succ m, 1 -> Cons hd tl => take n 1 -> Cons hd (take m tl) ; 

— The first condition simplifies the function argument n, checks whether this is 
non-zero and introduces its predecessor as the fresh variable m; 

— The second condition uses the function argument 1, checks whether it is a non- 
empty list and introduces its head as the fresh variable hd and its tail as the 
fresh variable tl; 

— The result is expressed using the fresh variables introduced in the conditions. 



Fig. 3. Semantics of a JSL rule 



Application: JSL Specification of the JavaCard Virtual Machine To 

illustrate JSL, we take the formalisation of the JCVM as an example. This 
application has been the initial motivation for the work on Jakarta. The JSL 
specification of the JCVM is derived automatically from the CertiCartes formal- 
isation of the JCVM in Coq. 

Basically, the JCVM is described as a state transformer: execution of an 
instruction modifies the internal state space. The virtual machine takes as in- 
put the initial state space, and a program (in cap-format) and executes the 
appropriate code. The state that is produced by an instruction is tagged with 
a label Normal or Abnormal. If the state is tagged with Abnormal, this means 
that something bad has happened: either an exception has been thrown (and 
not been caught), or there is an error in the bytecode, noticed by the virtual 
machine. These errors in the bytecode normally are found by a bytecode veri- 
fier. That we are still checking for these kind of errors makes our virtual machine 
defensive, i.e. we do not expect the input program to be certified. By making 
different abstractions of a defensive virtual machine, one can construct different 
bytecode verifiers. 

To illustrate the virtual machine, we give the semantics for the negation 
instruction NEG. Its CertiCartes definition reads as follows. 

Definition NEG := [t :type_prim] [state : jcvm_state] 

Cases state of 

(sh, (hp, (cons h If))) => 

Cases (head (opstack h) ) of 

(value x) => (* if the value pushed from the stack is typed by t *) 

(* then the NEG operation is performed *) 

Cases X of ((Prim tx) , vx) => 

(if (beq_primitive_type t tx) 
then (update_frame 

(update_opstack (cons ((Prim t) , (t_minus t ZERO vx)) 
(tail (opstack h) ) ) 
h) state) 

else (AbortCode opstack_error state)) | 
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=> (AbortCode opstack_error state) 

end I 

error => (AbortCode opstack_error state) 
end I 

=> (AbortCode state_error state) 
end. 

This instruction assumes that there is a primitive value on the top of the 
operand stack, and replaces it with its negated value. The Jakarta toolset trans- 
forms this into the following JSL rewrite rules^. 

function neg : type_prim -> state -> returned_state := 
begin 

s -> {static = sh; heap = hp; stack = Nil} 

=> neg p s -> Abnormal s Error; 

s -> {static = sh; heap = hp; stack = Cons f If}, 

f.opstack -> Nil 

=> neg p s -> Abnormal s Error; 



s -> {static = sh; heap = hp; stack = Cons f If}, 
f.opstack -> Cons o os, 
o -> {data_type = Ref r; value = k} 

=> neg p s -> Abnormal s Error; 

s -> {static = sh; heap = hp; stack = Cons f If}, 

f.opstack -> Cons o os, 

o -> {data_type = Prim p^; value = k}, 

p == p^ -> false 

=> neg p s -> Abnormal s Error; 



s -> {static = sh; heap = hp; stack = Cons f If}, 
f.opstack -> Cons o os, 
o -> {data_type = Prim p^; value = k}, 
p == p^ -> true 
=> neg p s -> 

Normal (s with 

{stack := Cons (f with {p_count := Succ (f.p_count); 

opstack := Cons ({data_type = Prim p; 

value = k}) os}) 



If}); 



end. 



Notice how these rules systematically consider all possible cases. 

A more complicated instruction to describe formally is invoke.virtual, 
which contains more different cases that might cause an exception or an error. 
Below we give the rewrite rule for the normal termination case, the complete 
formalisation also contains rules for all complementary cases. Exceptions are 
thrown if this instruction is called with a null pointer argument or if there is 

Notice that we have changed some tuples to labelled tuples or records. 



1 
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a security problem, signalled by the function t e st_se cur it y_invoke virtual. 
In all other cases, an error in the bytecode is signalled. The JSL specification 
closely follows the JCVM specification. The reader is not expected to understand 
all the details of this formalisation, but hopefully appreciates how the rewrite 
rule encodes the evaluation order in a natural way. Again, this formalisation is 
derived from our earlier work on CertiCartes. 



function invoke_virtual : nat -> class_method_idx -> state -> 

capprogram -> returned_state := 

begin 

s -> {static = sh; heap = hp; stack = Cons f If}, 
nargs -> Succ n, 

nth_func f.opstack nargs -> {data_type = Ref r; value = vx}, 
vx == null -> False, 



nth_func hp vx -> ob, 

nth_elt cap. classes (get_obj_class_idx ob) -> c, 
get_method c cm_id -> m, 
take nargs f.opstack -> 1, 
drop nargs f.opstack -> 1 \ 
test_security_invokevirtual f ob -> True, 
signature_verif ication (datalist_to_typelist 1) 
m. domain cap -> True 
=> invoke_virtual nargs cm_id s cap -> 

Normal (s with 

{stack := (Cons {opstack = Nil; 

locvars = make_locvars 1 m. local; 
method_loc = m.method_id; 
context_ref = get_owner_context ob; 
pc = Zero} 

(Cons (f with {opstack := IG) 
If))}); 



end. 



3 The Jakarta Prover Interface 

Proof assistants such as Coq support the definition of total, terminating recursive 
definitions through the combination of fixpoint definitions and case analysis. 
Under suitable circumstances, which we describe below, it is possible to compile 
JSL functions into recursive definitions d la Coq. In order to target several proof 
assistants, prototyping environments and programming languages, we translate 
JSL specifications first into an intermediate language JIR (Jakarta Intermediate 
Representation language), supporting such recursive definitions. 



The Jakarta Intermediate Representation language (JIR) The Jakarta 
Intermediate Representation Language is a mild extension of JSL with case 
expressions. 
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Definition 4. Let E he a signature. 

— The set f + of JIR expressions ( over E) is defined by the abstraet syntax: 

£+ .-y\£+ ==S+ \c£+ \ f £+ \ case £+ of {M} 
where the set M of matches is defined as: 

M := 0 \M\p^£ 

— A JIR rewrite rule is a rewrite rule of the form 

f X ^ e 

where x = (xi, ... are pairwise distinet variables and e e £~^ verifies 

var(e) C {xi, . . . ,x^}. The set of JIR rewrite rules is denoted by T^jir. 

Compiling JSL Specifications The Jakarta Prover Interface JPI transforms 
deterministic JSL functions into JIR functions. The transformation may fail, for 
example if the rewrite system is not deterministic. If it succeeds, it transforms 
a set of /-rewrite rules into a recursive function definition a la Coq. The func- 
tion K is defined thanks to an auxiliary recursive function K' which transforms 
a set of rewrite rules into a single case expression. 

Definition 5. 

— We define K' : R ^ £~^ as follows: 

K'm,{e,d))})=d 
K'{Xi, ... ,Xk)=case t of 

{pi ^ K' {X[) I 

Pk ^ K' (X')} 

where in the last elause it is assumed that pi , ... , are pairwise distinet 
(for the deeomposition to be unique) and: 

• for every 1 < i < k and R G Xi, head (tt R) = (t^pi); 

• for every I < i < k, X'- = {(tail (tt i?), it' R) \ R E X^}. 

— We define K ^ Hjir cls follows: 

^ ^ ^ '^i}) = / ^ ^ f ^ ^i}) 

where it is assumed that x = (xi, ... ,Xg) are pairwise distinet. 

In other words, K proceeds by checking that all the left-hand sides of the rewrite 
rule coincide before calling the auxiliary function K' . The function K' proceeds 
by first partitioning the set of rewrite rules on the right-hand side of the first 
condition, and then making recursive calls on the partitions, leaving out the first 
condition. 



12 



G. Barthe et al. 



Note that in practice, the function is parameterised by a predicate which 
ensures that the resulting function is of a suitable shape; for example, the predi- 
cate (p can be used to enforce that the resulting function is total (case expressions 
must be exhaustive and treat all the possible cases) and unambiguous (the pat- 
terns of a case expression must be non-overlapping). 

JIR expressions can easily be transformed into input for a specific proof 
assistant or programming language (to provide execution). Currently our tool 
supports the proof assistant Coq and the programming language OCaml and we 
are extending it to support other tools. 

We have also implemented a decompiler which transforms case expressions 
into rewrite rules. The decompiler can be used to translate Coq formalisations 
to JSL. Notice that the decompiler J is the inverse of the compiler K. 

Definition 6. We define J : T^jir as follows: 

Jif x^e) = {{{), {g,e))} 

if e is not a ease- expression 

J{f X ^ case M of {pi ^ ei I ... \pk Ck}) = 

Ui<j<fe {((M,p,) : (^ R), R) I ReJ{f e,)} 

4 The Jakarta Transformation Kit 

The core of Jakarta’s functionality is the Transformation Kit, which provides 
interactive support for abstractions. As emphasised in the introduction, the con- 
strained format of JSL facilitates (1) manipulation of JSL specifications, and 
(2) development of automatic transformation procedures for this purpose. Be- 
low, we will sketch how JTK provides support for abstractions, the support for 
refinements will be similar. 

The user of Jakarta specifies an abstraction function (in JSL), describing 
how the abstract state is constructed from the concrete one. For example, the 
so-called Type’ abstraction, which removes all values, will contain the following 
rewrite rule (among others, that propagate this abstraction to the level of states): 

X -> {data_type = t; value = v} => abs_type x -> {data_type = t} 

The user can tell the JTK to apply this abstraction to a particular JSL 
function. The JTK performs a syntactical transformation, applying the abstrac- 
tion function to every component of the rewrite rules, defining the function. 
For example, applying the type abstraction to invoke.virtual (as defined in 
Section 2) will change the 3'^^ condition into: 

nth_func f.opstack nargs -> {data_type = Ref r}, 

After applying this abstraction, the toolset will signal that there are problems 
with several conditions, and with the right-hand side of the conclusion of the 
rewrite rule, because variables are used which have not been introduced before 
(conflicting with the 3^^^ condition on rewrite rules. Definition 2). E.g., the 
condition uses the variable vx, which is not introduced in the abstracted version 
of the 3^^ condition. 
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The user analyses the outcome of the syntactical abstraction and determines 
what should be changed. For example, in the case of the invoke.virtual in- 
struction, the 6^^ condition describes the lookup of the dynamic type of an 
object. In the abstract virtual machine, there are no values, and one can only 
lookup the static type of a variable. Therefore, the user specifies how this condi- 
tion should be replaced, by another condition, introducing the variable c. These 
replacements identify the crucial steps in the abstraction. 

Finally, the JTK performs some cleaning, removing conditions which still 
depend on variables that have not been introduced before. The abstraction pro- 
cess, including replacements, is stored in a so-called abstraction script^ in order 
to guide the correctness proof of the abstraction. 

5 The Jakarta Automation Kit 

As emphasised in the introduction, the constrained format of JSL facilitates (1) 
reasoning about JSL specifications (2) developing automatic proof procedures 
for this purpose. We are currently developing a repository of tools to generate 
proof rules and tactics to reason about executable specifications. This repository, 
which is called the Jakarta Automation Kit, is tool-specific and oriented towards 
Coq. However, its underlying principles are applicable to other proof assistants. 

One of the proof techniques to reason about JSL functions is the so-called 
inversion principle. For every function /, an associated inversion principle is 
derived, based on an analysis of the rewrite rules defining /. Given a predicate 0, 
relating /’s input to its output, application of the inversion principle breaks down 
the proof of Vcc : tr. 0 (cc, f x) into several smaller subgoals. For each rewrite 
rule defining /, a subgoal is generated with the following format: assuming that 
all left-hand sides of the conditions can be rewritten in their right-hand sides, 
and assuming that / x rewrites into an expression d (as specified by the rewrite 
rule), one shows that 0 (x, f x) holds. 

For example, to show the correctnes of the bytecode verifier, one has to show 
that for every instruction, execution commutes with the abstraction function. 
Suppose we have a predicate P specifying this. Then, in particular we have to 
show in Coq: 

(nargs : nat) (cm_id : class_method_idx) (s : state) (cap : j cprogram) 

(P nargs cm_id s cap (invoke_virtual nargs cm_id s cap)) 

(where invoke.virtual is described in Section 2). Application of the inversion 
principle reduces this goal to several subgoals (one for each defining rewrite rule) , 
including the following subgoal: 

(nargs : nat) (cm_id : class_method_idx) (s : state) (cap : j cprogram) 

(shisheap) (hpiheap) (f : frame) (If : stack) (n:nat) (r :type_ref) (vx:Z) 

(obiobj) (c: Class) (m: Method) (1,1^ : (list vain)) 

(s = (Build_state sh hp (Cons f If))) 

-> (nargs = (S n)) 

-> ((Nth_func (opstack f) nargs) = (Build_data (Ref r) vx)) 

-> ((vx = Null) = False) 
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-> ( (Nth_f unc hp vx) = ob) 

-> ((Nth_elt (classes cap) (get_obj_class_idx ob)) = c) 

-> ( (get_method c cm_id) = m) 

-> ((take nargs (opstack f)) = 1) 

-> ((drop nargs (opstack f)) = IG 

-> ( (test_security_invokevirtual f ob) = True) 

-> ( (signature_verif ication (datalist_to_typelist 1) 

(domain m) cap) = True) 

-> ( (invoke_virtual nargs cm_id s cap) = 

(update_stack (Cons (Make_frame Nil 

(make_locvars 1 (local m) ) 

(method_id m) 

(get_owner_context ob) 

0 ) 

(Cons (update_opstack 1^ f ) If)) s)) 

-> (P nargs cm_id s cap (invoke_virtual nargs cm_id s cap)). 

Using rewriting, this subgoal can be simplified further. 

We have proven the commutation property before, without using the inver- 
sion principle, and in our experience, using the inversion principle is very useful: 
by pulling out all the different cases at once, it allows to simplify the goals by 
applying suitable rewriting tactics at the onset of the proof. Consequently, the 
proofs become shorter and are much easier to perform and understand, resulting 
in a substantial increase in the speed of proving. Without the inversion principle 
the proof took a few days (and we were often faced with goals that were more 
than 3 pages long!), while using the inversion principle it only took a couple of 
hours to complete the proof. 

6 Conclusion 

We have described the general structure of the Jakarta toolset, which provides a 
tool-independent front-end to specify and reason about the JavaCard platform. 
In particular, the toolset provides support to construct abstractions, in order to 
derive certified bytecode verifiers from the formalisation of the JavaCard virtual 
machine. 



6.1 Related Work 

Prototyping Environments and Proof Assistants The Jakarta Prover In- 
terface provides a “shallow embedding” of JSL into proof assistants such as 
Coq and programming languages such as Caml — the embedding is called shal- 
low because we do not formalise the syntax of JSL as datatypes in the tar- 
get language, as a deep embedding would do. Several implementations relate 
such environments, including B, VDM, Z and Centaur, to proof assistants, see 
e.g. [1,11,26,34]. In contrast to Jakarta, these specification languages are ex- 
tremely powerful, which makes it difficult to generate proof principles for the 
specifications automatically. 
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Abstractions The idea of deriving abstract functions from a concrete function 
and an abstraction function, which traces back to Cousot and Cousot’s seminal 
paper [14], see also [12,13], has been exploited in a number of contexts, and in 
particular in the context of formal verification, see e.g. [4,8,17] for recent exam- 
ples. Our work around JTK can be viewed as a simple application of abstract 
interpretation techniques to term-rewriting. 



Applications to JavaCard Jakarta is tailored to the design of certified byte- 
code verifiers. There have been a number of related efforts, both to prove the 
standard bytecode verifier correct [7,27,33], and to suggest new bytecode verifiers 
based on more complex type systems [25]. Most of this work is tailored towards 
a particular security policy, to the exception of [27], where it is shown how to 
use a data flow analyser to construct a bytecode verifier from an abstract virtual 
machine. In contrast, our work is focused on deriving abstract virtual machines 
from defensive ones, and proving them correct. We are not aware of any similar 
effort, despite tremendous activity in the field — see e.g. [19] for a recent survey 
of ongoing work. 



6.2 Future Work 

The paper reports on preliminary results with the implementation and use of 
Jakarta. Clearly, much work remains to be done, e.g. extending JSL with mod- 
ules, extending JPI to support other proof assistants, programming languages, 
and modifying JPI to translate JSL specifications as inductive relations. . . Below, 
we single out two important directions for future research. 

JAK: Automating Correctness Proofs for Bytecode Verifiers We in- 
tend to combine the correctness proof of the data flow analyser of [27] with the 
correctness proofs for abstract virtual machines to achieve modular, highly au- 
tomated proofs of correctness for a range of bytecode verifiers. As a first step in 
this direction, N. Baudru, S. Coupet-Grimal and D. Sanchez have ported Nip- 
kow’s development to Coq. Hence future work only needs to focus on automating 
the proof of correctness of abstract virtual machines. This involves automating 
the proof of 

V®. (a ifx)) G l(ax) 

where a is the abstraction function, / is the function to be abstracted and / is the 
abstracted function — in some instances, the result only holds up to subtyping, 
see e.g. [3]. To this end, one needs to automate the proof of the inversion principle 
for / and to perform rewriting steps to conclude — in most cases, these two passes 
are sufficient; for instructions such as invoke.virtual, some further reasoning 
is required. In the latter case, we need to integrate rewriting techniques into Coq 
so that rewrite steps in the JSL execution model are translated into proof terms 
acceptable by Coq. 
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In order to apply our methodology, we are currently extracting an offensive 
virtual machine from our specification and building up appropriate defensive 
virtual machines that verify (1) initialisation and (2) information fiow. 

JTK: Support the Construction of Refined Virtual Machines Currently, 
JTK only supports abstractions. We are planning to extend it to support inter- 
active refinements, i.e. tools to define a function f \ a' ^ a' from a previously 
defined function f : a ^ a and a refinement function a : a' ^ a; here it is 
assumed that cr' is more precise than a, and that a forgets some of the informa- 
tion contained in a' . In the context of reasoning about the JavaCard platform, 
refinement is useful e.g. to construct a JCVM with a more precise memory 
model — currently our formalisation does not treat transient objects. 
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Abstract. Paulson’s Inductive Approach for verifying traditional cryp- 
tographic protocols is tailored to those where agents make use of smart 
cards. An intruder can actively exploit other agents’ cards, which can be 
stolen or cloned. The approach is demonstrated on the Shoup- Rubin pro- 
tocol, which is modelled and verified thoroughly. The protocol achieves 
strong goals of confidentiality, authentication and key distribution. How- 
ever, our proofs highlight that a few messages require additional explic- 
itness in order to guarantee those goals to the peers when the cards’ data 
buses are unreliable. 

Keywords: smart card protocols. Inductive Approach, confidentiality, 
authentication, key distribution. 



1 Introduction 

Smart card technology attempts to strengthen modern security protocols by of- 
fering essential computational power and data storage with high resistance to 
external tampering. Typically, all long-term secrets are stored into the cards, 
so each agent merely needs to remember the PIN to activate his own card. An 
increasing number of companies are considering the purchase of smart cards and 
related protocols at present. However, if on one side smart cards have become 
inexpensive, on the other side there still exists stringent demand for adequate 
guarantees that the new technology is worth buying. To our knowledge, the ma- 
jor attempt of satisfying that demand by mathematical proofs is due to Shoup 
and Rubin [14]. They take into account an existing session key distribution pro- 
tocol due to Leighton and Micali [10], which does not use smart cards, and prove 
it secure using Bellare and Rogaway’s notion of provable security. In short, this 
amounts to a complexity-theoretic study of confidentiality, which is conducted 
under the assumption that pseudo-random functions exist. Shoup and Rubin 
also design a new protocol for session key distribution in a three-agent setting 
where each agent is endowed with a smart card. Finally, they extend Bellare 
and Rogaway’s approach to account for smart cards, and prove that the new 
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protocol keeps the session keys confidential. Their proofs are conducted with- 
out mechanical tools. Shoup and Rubin’s protocol was later implemented by 
Jerdonek et al. [9]. 

We have introduced a realistic treatment of smart cards into Paulson’s In- 
ductive Approach for verifying security protocols [12], which is mechanised by 
the interactive theorem prover Isabelle [11]. The protocol model is constructed 
by induction, so it allows an unbounded number of agents to interleave an un- 
bounded number of protocol sessions. An intruder is modelled, spy below, who 
can exploit an unspecified set of stolen smart cards by preparing queries that 
conform to the cards’ functional interface. The spy has reverse engineered an- 
other unspecified set of cloned cards and has discovered their internal secrets. 
The two sets are in no way related with each other so to model all possible con- 
ditions of the cards. The approach scales up, at the price of minor modifications, 
to all smart card protocols regardless of whether they assume secure or insecure 
means between agents and cards. 

We demonstrate our extended approach on the Shoup-Rubin protocol, and 
verify its goals of confidentiality, authentication and key distribution. Our anal- 
ysis supports the claim that the protocol achieves strong goals. However, if the 
data buses of the smart cards are corrupted so to produce outputs in an unspec- 
ified order, then two of the protocol messages necessitate extra explicitness to 
confirm the goals to the peers. The corresponding proofs suggest a simple fix. 

The main results achieved by this paper are: (i) tailoring the Inductive Ap- 
proach to the analysis of protocols based smart cards; (ii) the first full mech- 
anisation (formal verification supported by a mechanised tool) of a provably 
secure protocol based on smart cards; (hi) the discovery that the protocol needs 
additional explicitness to achieve its goals of confidentiality, authentication and 
key distribution when the cards’ buses are unreliable; (iv) a fix to that need of 
explicitness. The paper gives an abstract presentation of the Shoup-Rubin pro- 
tocol (Sect. 2), and outlines our extensions to the Inductive Approach (Sect. 3). 
It goes on with the inductive modelling of the protocol (Sect. 4) and its verifica- 
tion (Sect. 5). Then, it analyses a version of the protocol with added explicitness 
(Sect. 6) and concludes (Sect. 7). 

2 The Shoup-Rubin Protocol 

This protocol presupposes that each agent P has a long-term key Kp that is 
stored into the agent’s card Cp and is shared with the server. The card also stores 
its own long-term key Kcp- All keys are symmetric. The concept of pairkey (due 
to Leighton and Micali [10]) is adopted to establish a long-term secret between 
the smart cards of a pair of agents. The pairkey is historically referred to the 
pair of agents: the one for agents A and B is II ab = {|A[[^^0{|H[}^^^, where 
0 is the exclusive-or operator. While A’s card can compute and then 

TTab = from Bab, B^s card can compute iTab directly. Hence, the two cards 

share the long-term secret Tr^b, which we call pair-k for A and B. The main goal 
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The Shoup-Rubin protocol 



of the protocol is distributing a session key, which is computed by the smart 
cards out of a pair-k and a nonce as explained below. 

The full protocol (Fig.l) develops through seven phases. The odd ones take 
place over the network, while the even ones concern the communication between 
agents and smart cards. 

Phase I. An initiator A tells the trusted server that she wants to initiate a 
session with a responder 5, and receives in return the pairkey ITab and its 
certificate encrypted under her long-term key. 

Phase II. A queries her card and receives a fresh nonce and its certificate 
encrypted under the card’s long-term key. (The form of A’s query is specified 
neither by the designers nor by the implementors, so our choice of message 
3 is arbitrary). 

Phase III. A contacts B sending her identity and her nonce Na. 

Phase IV. B queries his card with the data received from A, and obtains a new 
nonce Nb, the session key Kab^ a certificate for Na and Nb, and a certificate 
for Nb] Kab is constructed by a function of Nb and tt^^. 

Phase V. B forwards his nonce Nb and the certificate for Na and Nb to A. 
Phase VI. A feeds her card 5’s name, the two nonces (she has just received 
A6), the pairkey and its certificate, the two certificates for the nonces; A’s 
card computes iTab from Bab and uses it with the nonce Nb to compute the 
session key Kab; the card outputs Kab and the certificate for Nb, which is 
encrypted under TTab- 

Phase VII. A forwards the certificate for Nb to B. 
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The protocol assumes secure means between agents and cards, so the spy can- 
not overhear the messages in transit between an agent and his card. The cards 
indeed output the session keys in clear. Although this assumption may seem 
unrealistic to make on a vast scale, in general it adds robustness to a protocol 
by reducing each agent’s knowledge to the PIN to activate his card. The Shoup- 
Rubin protocol also works with cards that are not pin-operated, so agents know 
no long-term keys and can only identify the messages by the fact that they are 
compound or not. All encryption and decryption operations are performed by 
the smart cards. Should the spy steal a card, she would gain the card’s compu- 
tational power; should the spy also clone the card, she would also discover the 
card’s stored secrets. In either case, the spy can discover a session key only by 
feeding the card the specific inputs that produce that key. 

Also, certain features of the protocol design, such as both A and 5’s nonces 
sent in the clear (messages 5 and 8), may seem incautious, but an informal 
account for the consequences can be hardly given. In particular, 5’s nonce is 
used to compute the session key, but we formally verify that intercepting that 
nonce does not help the spy discover the session key as long as she cannot use A 
and 5’s cards. 

3 Extending the Inductive Approach 

Smart Cards. We associate a new type to the smart cards and define a func- 
tion Card mapping the agents to their respective cards. Recall that agent is 
the Isabelle datatype for agents [12, Sect. 3.1] and includes: the trusted third 
party. Server (often abbreviated in S); a malicious eavesdropper. Spy; unlimited 
“friendly” agents. Friend i (i being a natural). The agents are associated to their 
keys shared with the server by the function shrK [12, Sect. 3.5], and likewise we 
associate the smart cards to their long-term keys by a function crdK. For exam- 
ple, crdK(Card A) denotes A’s card’s key. The cards’ pins can be formalised in 
the same fashion. All these long-term secrets for a specific agent are are stored 
into the agent’s smart card, as formalised below by the functions knows and 
initState. 

We declare a set stolen of cards that can be used by the spy and not by 
their legal owners. Should the cards be pin-operated, the spy would also need to 
discover the pin to activate the stolen cards. She could do so either by monitor- 
ing the network or by colluding with the card’s owner (the latter chance can be 
formally defined by trivial updates to the function initState, Sect. 4). Addition- 
ally, the spy may use modern techniques (such as microprohing [2]) to break the 
physical security of the card, access its EEPROM where the long-term secrets 
are stored and, in the worst case, reverse engineer the card’s chip. At this stage, 
the spy would be able to build a clone of the card for her own use. Such cards 
are modelled by the set cloned. 

The two sets are not related with each other, so that a card could even be 
temporarily stolen, then cloned, and finally returned to the owner, resulting in 
the set cloned but not in the set stolen. This seems impossible by current cloning 
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techniques, which are invasive and therefore unrecover ably damage the original 
card, but in fact the spy could build two clones and return one to the unaware 
owner. The protocol model allows the spy to use her own card and those that are 
either stolen or cloned (Sect. 4.6). We assume that the cards’ buses are unreliable 
as explained below. 



Events. The existing approach includes a datatype event that formally allows 
three possible events: Says AB meaning that agent A sends agent B a mes- 
sage X ; Notes AX, meaning that A notes down X [12] ; Gets B X, meaning that B 
receives X [3]. We extend that datatype with two new events: Inputs MCX, 
meaning that agent A queries card C with message X; Outputs C MX, meaning 
that card C responds to agent A with message X. When an agent queries his 
card with a message, then the card certainly receives the message if the com- 
munication means is assumed to be secure, as with the Shoup-Rubin protocol. 
The same applies to a card’s response in transit in the opposite direction. With 
protocols that assume insecure means between agents and cards, reception is 
not guaranteed because the spy can intercept any messages in transit, so two 
additional events modelling reception on both sides are needed. 

A list of events, trace in the sequel, occurring when an (unbounded) popu- 
lation of agents run a protocol may be interpreted as a possible history of the 
network where the protocol is executed. The set of all possible traces is the for- 
mal model for the protocol [12]. Since the model is defined by induction, no event 
is forced to happen on a generic trace. This feature also formalises the failure 
mode of smart cards: the model cards can stop working at any time. Besides, 
events can take place in any order, so if a message X is sent in the network ear- 
lier than X', it could be received later than X'. Likewise, if X is input to a card 
earlier than X', the card could produce the output for X later than that for X'. 
This signifies that the cards’ data buses are unreliable so to give outputs in an 
order that is not influenced by the order of the inputs. The more permissive is 
the model, the broader are the properties that can be investigated. 



Agents’ Knowledge. The knowledge that each agent derives from a trace of 
events is formalised by the function knows [4, Sect. 3], which takes as inputs an 
agent name and a trace, returning a set of messages. The function is defined 
inductively by the following six rules. We have added the last two to account for 
the events pertaining to the smart cards. 

1. An agent knows his initial knowledge (which is defined in the next section). 

2. An agent knows what he alone sends to anyone on a trace; in particular, the 
spy also knows all messages that anyone sends on it. 

3. An agent knows what he alone notes on a trace; in particular, the spy also 
knows compromised agents’ notes. 

4. An agent, except the spy, knows what he alone receives on a trace. 

5. An agent knows what he alone inputs to any card on a trace. 

6. An agent knows what he alone is output from any card on a trace. 
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Case 4 states that the spy’s knowledge must not be extended with any of the 
received messages because the formal protocol model (Sect. 4.1) only allows 
reception of those messages that were sent, so the spy already knows them by 
case 2. The last two cases also apply to the spy, so she only knows the inputs that 
she produces or the outputs that are addressed to her, for the means between 
agents and cards is secure. 

4 Modelling Shoup-Rubin 

The protocol never uses pair keys to encrypt, so we model them as nonces, which 
are natural numbers. On the contrary, the pair-k’s are used as proper keys. The 
session keys are computed out of nonces and pair-k’s. The following functions 
construct these components. 

- Pairkey : agent * agent — > nat 

- pairK : agent * agent — > key 

- sesK : nat * key — > key 

At the operational level, we are only interested in their abstract properties. 
For example, the function Pairkey cannot be assumed collision- free because it 
is implemented in terms of the exclusive-or operator, but we can assume that 
collision of keys is impossible. 

We can now define the function initState for Shoup-Rubin, formalising the 
agents’ initial knowledge. The server’s comprises all long-term secrets. 

initState S = {Key (crdK C)} U {Key (shrK A)} U 

{Key (pairK(A, B))} U {Nonce (Pairkey(A, B))} 

The friendly agents’ initial knowledge is empty, so they cannot reveal secrets to 
the spy. 

initState (Friend i) = {} 

The spy’s initial knowledge comprises all long-term secrets stored into cloned 
cards and those obtainable from them. From the definitions of pairkeys and 
pair-k’s (Sect. 2), it follows that the spy can forge the pair-k for a pair of agents 
in case the card of the second agent is cloned, and a pairkey if both the corre- 
sponding cards are cloned. 

initState Spy = {Key(crdKC) | C G cloned} U 

{Key(shrKA) | (Card A) G cloned} U 
{Key (pairK(A, 5)) | (Card B) G cloned} U 
{Nonce (Pairkey(A, 5)) | (Card A) G cloned A 

(Card B) G cloned} 

We declare the constant shouprubin as a set of lists of events. It designates 
the formal protocol model and is defined in the rest of the section by means of 
inductive rules. The rules for phases III, V and VII are omitted here for space 
limitations. 
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4.1 Basics 

The empty trace formalises the initial scenario, where no protocol session has 
begun. Rule Base settles the base of the induction stating that the empty trace 
is admissible in the protocol model. All other rules represent inductive steps, so 
they detail how to extend a given trace of the model. Rule Reception [3] allows 
messages sent in the network to be received by their respective intended recip- 
ients: once the trace evsR of the protocol model contains the event whereby A 
sends X to then evsR extended with the event whereby B receives X is still 
a trace of the model. All other rules have the same syntax. 

Base 

[ ] G shouprubin 

Reception 

[| evsR G shouprubin; Says A B X G set evsR |] 

Gets B X # evsR G shouprubin 



4.2 Phase I 

Any agent except the server may initiate a protocol session at any time, hence the 
corresponding event may extend any trace of the model (SRI). Upon reception 
of a message quoting two agent names — initiator and responder of the session 
— the server computes the pairkey for them and sends it with a certificate to the 
initiator (SR2). The pairkey itself does not reveal its peers, but the certificate 
explicitly associates it to its peers. 

SRI 

[| evsl G shouprubin; A ^ Server |] 

Says A Server {| Agent A, Agent B|} # evsl G shouprubin 



SR2 

[| evs2 G shouprubin; Gets Server {| Agent A, Agent B|} G set evs2 |] 
=> Says Server A {| Nonce (Pairkey (A, B) ) , 

Crypt (shrK A) {| Nonce (Pairkey (A, B) ) , Agent B|} 

I } # evs2 G shouprubin 



4.3 Phase II 

The initiator of a protocol session may query her own smart card provided that 
she received a message containing a nonce and a certificate (SR3). The initiator 
gets no assurance that the nonce is in fact the pairkey for her and the intended 
responder, or that the certificate is specific for the pairkey, because the message 
is compound. It would seem sensible that the agent forwarded the entire message 
to the smart card, which would be able to decrypt the certificate and verify the 
integrity and authenticity of the pairkey. However, the protocol specification 
does not state this, so we choose a simpler input message containing only the 
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initiator’s name. Given the input, the card issues a fresh nonce and a certificate 
for it (SR4). The card keeps no record of the nonce in order to conserve memory. 
The certificate will subsequently show the card the authenticity of the nonce. 
Both rules rest on a card that has not been stolen, so that it can be used by its 
owner. 

SR3 

[| evs3 G shouprubin; Card A 0 stolen; 

Says A Server {| Agent A, Agent B|} G set evs3; 

Gets A { I Nonce Pk, Cert | } G set evs3 |] 

Inputs A (Card A) (Agent A) # evs3 G shouprubin 



SR4 

[| evs4 G shouprubin; Card A 0 stolen; Nonce Na ^ used evs4; 

Inputs A (Card A) (Agent A) G set evs4 |] 

Outputs (Card A) A {| Nonce Na, Crypt (crdK (Card A)) (Nonce Na)|} 
# evs4 G shouprubin 



4.4 Phase IV 

This phase sees the responder forward a compound message received from the 
network to his smart card (SR6). The smart card issues a fresh nonce, computes 
the pair-k for initiator and responder, and uses these components to produce a 
session key. The nonce being fresh, the session key also results fresh. Finally, the 
card outputs the nonce, the session key and two certificates {SR7). One certificate 
establishes the association between the initiator’s nonce and the responder’s, and 
will be inspected by the initiator’s card in phase VI. The other certificate will 
be retained by the responder, who will expect it again from the network in the 
final phase. 

SR6 

[| evs6 G shouprubin; Card B 0 stolen; 

Gets B { I Agent A, Nonce Na|} G set evs6 |] 

=> Inputs B (Card B) {| Agent A, Nonce Na|} # evs6 G shouprubin 



SR7 

[| evs7 G shouprubin; Card B 0 stolen; 

Nonce Nb 0 used evs7 ; Key (sesK(Nb,pairK(A,B) ) ) 0 used evs7 ; 
Inputs B (Card B) {| Agent A, Nonce Na|} G set evs7|] 

Outputs (Card B) B {| Nonce Nb, Key (sesK(Nb,pairK(A,B) ) ) , 

Crypt (pairK(A,B)) {| Nonce Na, Nonce Nb|}, 
Crypt (pairK(A,B)) (Nonce Nb) | } 

# evs7 G shouprubin 



4.5 Phase VI 

The scenario returns upon the initiator. Before she queries her non-stolen card, 
she verifies having taken hold of three messages, each containing a nonce and 
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a certificate. She takes on trust the nonce Pk as the pairkey and Certl as 
its certificate, and recalls having obtained from her smart card a nonce Na 
and a certificate. Then, she treats Nb as the responder’s nonce and CertS as a 
certificate for Na and Nh. Finally, she feeds these components to her smart card 
(SR9). The card can verify that all the received components have the correct 
form and, if this is affirmative, computes the pair-k from the pairkey and then 
produces the session key and a certificate for the responder’s nonce {SRIO). 

SR9 

[| evs9 G shouprubin; Card A 0 stolen; 

Says A Server {| Agent A, Agent B|} G set evs9; 

Gets A { I Nonce Pk, Certl |} G set evs9; 

Outputs (Card A) A {| Nonce Na, Cert2|} G set evs9; 

Gets A { I Nonce Nb, CertS I } G set evs9 |] 

=> Inputs A (Card A) {| Agent B, Nonce Na, Nonce Nb, Nonce Pk, 

Certl, CertS, Cert2 | } 

# evs9 G shouprubin 



SRIO 

[| evslO G shouprubin; Card A 0 stolen; 

Inputs A (Card A) {| Agent B, Nonce Na, Nonce Nb, 

Nonce (Pairkey (A , B) ) , 

Crypt (shrK A) {| Nonce (Pairkey (A, B) ) , Agent B|}, 
Crypt (PairK (A,B)) {| Nonce Na, Nonce Nb|}, 
Crypt (crdK (Card A)) (Nonce Na)|} 

G set evslO |] 

Outputs (Card A) A {|Key (sesK(Nb,pairK(A,B) ) ) , 

Crypt (pairK(A,B)) (Nonce Nb) | } 

# evslO G shouprubin 



4.6 Threats 

Also the spy can act as a friendly agent and thus follow the rules given above. 
In addition, she may also act illegally. She observes the given trace, extracts all 
message components by the function analz, and builds all possible messages out 
of them by the function synth [12, Sect. 3.2]. She may send any of these fake 
messages in the network or input them to the cards that are either stolen or 
cloned. This is modelled by the following rule Fake. 

Fake 

[| evsF G shouprubin; Card A G stolen U cloned; 

X G synth (analz (knows Spy evsF)) |] 

Says Spy B X # Inputs Spy (Card A) X # evsF G shouprubin 

We assume that the algorithm used by the cards to compute the session keys 
is publicly known. Therefore, if the spy obtains a nonce and a pair-k, she can 
compute the corresponding session key (Forge), thus acquiring knowledge of it. 
Since the pair-k’s are never sent in the network, they can only be known initially 
(by definitions of initState and case 1 of knows). 
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Forge 

[| evsFo G shouprubin; Nonce Nb G analz (knows Spy evsFo) ; 

Key (pairK(A,B)) G knows Spy evsFo |] 

Notes Spy (Key (sesK(Nb,pairK(A,B) ) ) ) # evsFo G shouprubin 

The model must be extended to allow the spy to obtain the outputs of the cards 
that are either stolen or cloned. Therefore, we must introduce a further rule per 
each card’s output, formalising the fact that a card outputs towards the spy 
rather than its owner in case it lies in the spy’s hands. Rule SR4_Fake, built 
from SR4, is presented below, while rules SRTJFake and SRlOJFake, built in the 
same fashion from SR7 and SRIO respectively, are also needed but omitted here. 

SR4_Fake 

[| evs4F G shouprubin; Card A G stolen U cloned; 

Nonce Na 0 used evs4F ; 

Inputs Spy (Card A) (Agent A) G set evs4F | ] 

Outputs (Card A) Spy {| Nonce Na, 

Crypt (crdK (Card A)) (Nonce Na) | } 

# evs4F G shouprubin 
4.7 Accidents 

We complete the model by allowing accidents (or breaches of security) on session 
keys. This has been typically done by a single rule [8,12], or by two rules leaking 
two different kinds of session keys [7] . Shoup- Rubin requires both peers to handle 
the same session key, respectively in phases IV and VI. Therefore, the spy has 
a chance of learning the session key from both of them. In the worst case, she 
will also learn the nonce used to compute the key and the identity of its peers 
(Oopsi, Oops2). 

Oopsl 

[| evsOl G shouprubin; 

Outputs (Card B) B {| Nonce Nb, Key Sk, Cert, 

Crypt (pairK(A,B)) (Nonce Nb) | } 

G set evsOl |] 

Notes Spy {|Key Sk, Nonce Nb, Agent A, Agent B|} 

# evsOl G shouprubin 



Oops2 

[1 evs02 G shouprubin; 

Outputs (Card A) A {|Key Sk, Crypt (pairK(A,B)) (Nonce Nb)|} 

G set evs02 |] 

=> Notes Spy {|Key Sk, Nonce Nb, Agent A, Agent B|} 

# evs02 G shouprubin 

The spy cannot learn any pair-k’s by accident because no agent ever sees any. 

5 Verifying Shoup-Rubin 

While confidentiality is discussed in detail, authentication and key distribution 
are only introduced on an upgraded protocol (Sect. 6), due to space limitations. 
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5.1 Confidentiality 

Given a trace evs^ confidentiality of a message X on the trace is expressed as 
X ^ analz(knowsSpy evs)^ signifying that the spy cannot extract X from the 
analysis of the messages obtained from monitoring the trace evs. 

The confidentiality argument for a protocol responder B who is not the spy 
concerns the session key. Message 7 delivers the session key to B. The event 
formalising that message, Outputs (Card B) B {| Nonce Nb^ Key Sk^ Certl , Cert2\^ 
includes two certificates, Certl and Cert 2, that B cannot inspect because they 
are sealed by specific long-term keys (no agent knows any long-term keys). 

We have attempted to prove Sk confidential on a trace evs that contains no 
oops event leaking Sk but does contain the mentioned event. In the attempt, B^s 
card must be assumed not to be cloned otherwise the spy would know pairK(P, B) 
for any agent P and could forge the session key by rule Forge. The assumption 
that B is not the spy solves case SR 7, and the freshness assumption on the 
session key solves case SRT-Fake. Cases SRIO and SRIO-Fake remain unsolved. 
The former shows that P’s peer might be the spy, who could so obtain a copy 
of Sk from her own smart card and falsify the theorem. The latter subgoal 
shows that P’s peer’s card could be either stolen or cloned, so the spy would 
be able to use such card to compute Sk, regardless the identity of the card’s 
owner. These situations are due to the fact that, while P’s card issues a fresh 
session key in message 7, his peer’s card in fact computes a copy of that key 
out of available components in message 10. Therefore, solving the corresponding 
subgoals requires assuming that P’s peer is not the spy, and that P’s peer’s 
card cannot be used by the spy. But message 7 does not state the identity of 
such peer. This signifies that P gets no explicit information about the peer with 
which the session key is to be used, which violates a well-known explicitness 
principle due to Abadi and Needham [1, Principle 3]. If we inspect either one of 
the certificates, then the relevant assumptions can be stated and theorem 1 can 
be proved. Note that there is no need to assume P’s card not to be stolen — 
were it stolen, it would compute a fresh key. 

Theorem 1. If A and B are not the spy, A^s eard is neither stolen nor eloned, 
B ’5 eard is not eloned, and evs eontains 

Outputs (Card P) P {|Nonce Nb, Key Sk, Cert, Crypt(pairK(A, P))(Nonce Nb)} 
but does not eontain Notes Spy || Key 5A:, Nonce A6, Agent A, Agent Pj}', then 
Key Sk ^ analz(knowsSpy evs). 

From P’s viewpoint, trusting that his peer is not the spy and that his card cannot 
be used by the spy is indispensable. So is trusting that the key has not been 
leaked by accident. These assumptions, which are never verifiable, constitute 
the minimal trust [5,13]. However, P cannot even verify that the main event 
mentioned by the theorem ever occurs because he cannot inspect the encrypted 
certificate. Therefore, P certainly cannot apply the theorem, even under the 
minimal trust. 
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Analogous considerations apply to A’s viewpoint. Message 10 delivers the 
session key to A, so we attempt to prove that key confidential on the assump- 
tion that the event formalising message 10, Outputs (Card A) A || Key SA:, (7erA||, 
occurs. While the freshness assumption on the session key solves case SR7 as 
above, we need to assume that A’s card is neither stolen nor cloned to solve 
case SRIO-Fake, otherwise the spy could exploit A’s card to compute her copy 
of the session key. Cases SR7 and SRIO remain unsolved. The former highlights 
that A’s peer could be the spy. The latter highlights that, even assuming that A 
is not the spy, A’s card could be computing a session key already available to the 
spy who got it from A’s peer’s card. To solve these subgoals, we must assume 
that A’s peer is not the spy, and that A’s peer’s card is neither stolen nor cloned. 
But message 10 fails to express A’s peer. This theorem can be proved if the form 
of Cert is explicit, resulting in a guarantee that cannot be applied by A even 
under the minimal trust. These weaknesses were not highlighted by the provable 
security analysis. 

6 Verifying an Upgraded Shoup-Rubin 

Our findings suggest to upgrade the protocol so that both messages 7 and 10 
state explicitly the intended peer for the session key (Fig. 2). Quoting also the 
nonce in message 10 is not indispensable. It is straightforward to upgrade the 
protocol model accordingly. 



7. 

10. Ca^A: Nb,B , Kab, 

Fig. 2. Adding explicitness to two messages of Shoup-Rubin 



6.1 Confidentiality 

In the upgraded protocol model, two significant confidentiality theorems (2 
and 3) hold about the session key. 

Theorem 2. If A and B are not the spy, Ak eard is neither stolen nor eloned, 
B ’5 eard is not eloned, and evs eontains 

Outputs (Card B) B || Nonce Nb, Agent A, Key Sk, Certl , Cert2l 

but does not eontain Notes Spy {| Key SA;, Nonce A6, Agent A, Agent 5 [}-, then 



Key5A: ^ analz(knowsSpy evs). 
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Theorem 3. If A and B are not the spy, both A and B ’s eards are neither 
stolen nor eloned, and evs eontains 

Outputs (Card A) M || Nonce Nb, Agent B, Key Sk, Cert} 

but does not eontain Notes Spy {| Key SA:, Nonce 7V6, Agent Agent 5 then 

Key5A: ^ analz(knowsSpy evs). 

We prove these theorems following the reasoning developed in the previous sec- 
tion, which also motivates the assumptions about peers and cards. These theo- 
rems are applicable under the minimal trust by B and A respectively because 
the agents only need to verify the presence of the encrypted certificates without 
having to inspect them. If message 10 did not mention the nonce Nb, then theo- 
rem 3 would require a stronger assumption: the oops event universally quantified 
over the nonce it mentions. 

6.2 Authentication 

If B obtains the session key with the two certificates from his card and then 
receives the second of the certificates from the network, then theorem 4 states 
that A was alive and meant to communicate with him after he issued Nb. 

Theorem 4. If B is not the spy, both A and B ’s eards are neither stolen nor 
eloned, and evs eontains 

Outputs (Card B) B {| Nonce Nb, Agent A, Key Sk, Certl , Cert2l and 
Gets B {Cert 2) 

then evs also eontains 

Outputs (Card A) A ^ Nonce Nb, Agent B, Key Sk, Cert2}. 

The theorem certainly does not hold of the original protocol, where none of the 
two events verified by B expresses his peer A. The proof develops through the 
following steps. Since A is explicit in the first event, the complete form of Cert 2 
can be proved by induction. Because the means between agents and smart cards 
is secure, the second event (and not the first) implies that the certificate is known 
to the spy. Then, the authenticity argument for the certificate, omitted in this 
paper, derives that it originated with A in message 10 under the assumptions 
about peers and cards that theorem 4 reports. 

Likewise, upon reception of message 10, theorem 5 informs A that B was 
alive and meant to communicate with her. 

Theorem 5. If B’s eard is neither stolen nor eloned, and evs eontains 
Outputs (Card A) A \ Nonce Nb, Agent B, Key Sk, Cert2 1} 
then, for some Certl , evs also eontains 

Outputs (Card B) 5 || Nonce Nb, Agent A, Key Sk, Certl , Cert2^. 
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The theorem clearly does not hold of the original protocol, where A is not in- 
formed of her peer’s identity. Once we prove by induction that the main assump- 
tion of the theorem implies that the certificate is known to the spy, 

the authenticity argument for the certificate, omitted here, completes the proof 
of theorem 5 at the price of the assumptions on 5’s card. Unlike 5, A gets no 
assurances about how recently B was alive, because the event of the assumption 
contains no nonce invented by A [6]. 

Our theorems remark that the spy can impersonate any agent whose smart 
card is stolen or cloned: she just needs to intercept the relevant communication 
and to exploit that agent’s card to acquire the necessary message components. 



6.3 Key Distribution 

Applying the definition of knows to the authentication theorems, we can prove 
formally that the upgraded protocol meets the goal of key distribution and con- 
firms it to the peers. Theorem 6 formally assures agent A that the session key she 
receives is also available to her peer B. Theorem 7 provides the same guarantee 
to B. This goal cannot be proved formally of the original protocol because of 
the mentioned lack of explicitness. 

Theorem 6. If B is not the spy, both A and B ’s cards are neither stolen nor 
cloned, and evs contains 

Outputs (Card B) B || Nonce Nb, Agent A, Key Sk, Certl , Cert2l and 
Gets B {Cert 2) 

then Key Sk G analz(knowsA evs). 

Theorem 7. If B's card is neither stolen nor cloned, and evs contains 

Outputs (Card A) A || Nonce Nb, Agent B, Key Sk, Cert2l 
then Key Sk G analz(knows5 evs). 

7 Conclusions 

Our work makes Paulson’s Inductive Approach usable for analysing smart card 
protocols. We have mechanised the Shoup- Rubin protocol showing that it meets 
strong goals of confidentiality, authentication and key distribution. But two of 
the protocol messages must quote their intended recipients explicitly if the cards’ 
buses can output in a random order. Our theorems show that verifying smart 
card protocols requires significant man-effort in understanding the roles played 
by the cards and in realising how the messages they compute may influence 
the protocol goals. However, none of the theorems discussed here executes in 
more than 10 seconds on a 600Mhz Pentiumlll, so the computational resources 
necessary for the analysis are limited. 
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Abstract. Smartcards and PKCS #11 are an appealing solution for 
combined storage and certificate management at the enduser level. Many 
applications use PKCS #11 primitives for security reasons: a popular 
browser, like Netscape Navigator contain a PKCS #11 cryptographic 
module that plays a critical role in secure web surfing and e-mail signing 
and encryption. Nevertheless, most market-ready solutions ([SMARTSIGN], 
[GPKPKCS#11], [SLBCBPKCS#!!]) use non-programmable cards or 
else do not exploit the card’s programmable capabilities. Instead they 
utilize cryptographic functions built into the card. This results in appli- 
cations having the card manufacturer’s semantics instead of PKCS #11 
semantics. 

In this article we present our work: Java Card Certificate Management 
(JCCM). JCCM moves PKCS #11 middleware into the card it- 
self. This results in greater flexibility and less implementation de- 
pendence for applications. We have developed JCCM for two cards: the 
GemXpresso RAD 211is and the Cyberflex for Linux Starter’s 
Kit 2.1. We have also developed the corresponding dynamic library for 
Netscape enabling our endusers to use JCCM in their daily. 



1 Introduction 

The number of users with Internet access keeps growing, and so do their security 
needs. The increasing number of sites offering sensitive information (like bank 
accounts) via HTTPS [HTTPS] protocol is an example. International e-mail, 
the “intelligence is in the net” -approach in network computing and e-business 
demand stronger security. Browsers do implement secure web surfing and digital 
signed and encrypted e-mail using digital certificates ([X.509]), but they lack 
corresponding secure certificate storage mechanisms. 

Smartcards are tamper-proof devices, where tamper-resistance is a term 
with practical connotation that takes into account the cost/benefit relation of 
the attacks. Given unlimited funds we could break the security of a card. In 
[USENIX 99] some sophisticated chemical and physical attacks are described, 

* This work has been partially supported by the project E-TICKET CYCYT 
N^2FD1997-1269-C02-01(TEL) 
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together with effective and low-cost countermeasures. The article concludes that 
they see no really effective short-term protection against carefully planned in- 
vasive tampering (involving focused ion-beam tools). “Zeroization” mechanisms 
for erasing secrets when tampering is detected require a continuous power sup- 
ply that the credit-card form factor does not allow. The attacker can thus safely 
disable the zeroization mechanism before powering up the processor. 



2 The PKCS #11 Standard 

RSA Laboratories has developed, in cooperation with representatives of indus- 
try, academia and government, a family of standards called Public-Key Cryp- 
tography Standards, or PKCS for short. These standards cover RSA encryption, 
Difhe- Heilman key exchange, password-based encryption, an extended-certificate 
syntax, cryptographic message syntax, private key syntax, and certification re- 
quest syntax, as well as selected attributes. 



Table 1 . A significative set of Cryptoki functions 



General purpose 


Slot and token 


Cryptographic functions 


funtions 


management functions 


C_EncryptInit 


C_Initialize 


C_GetSlotList 


C_Encrypt 


C_Finalize 


C_GetSlotInf 0 


C_DecryptInit 


C_GetInf 0 


C_GetTokenInf 0 


C_Decrypt 


Objects management 


C_GetMechanismList 


C_SignInit 


functions 


C.SetPIN 


C_Sign 


C_CreateObject 


Session management 


C_Verif yinit 


C_CopyObject 


functions 


C.Verify 


C_DestroyObject 


C_OpenSession 


C_DigestInit 


C_GetAttributeValue 


C_CloseSession 


C_Digest 


C_SetAttributeValue 


C_CloseAllSessions 


C_GenerateKey 


C_FindObjectsInit 


C_GetSessionInf 0 


C_GenerateKeyPair 


C_FindObjects 


C_Login 


C_WrapKey 


C_FindObjectsFinal 


C_Logout 


C_UnwrapKey 



The PKCS #11 specifies an application programming interface (API) for 
cryptographic services, called Cryptoki, short for “cryptographic token inter- 
face” . Cryptoki isolates an application from details of the cryptographic device, 
which is called “token’. Portable cryptographic tokens, such as smartcards, are 
inserted in “slots”, which correspond to a physical reader or other device in- 
terface. A token stores objects and can perform cryptographic functions on it. 
Cryptoki defines three classes of object: data, certificates, and keys. A data 
object is defined by an application. A certificate object stores a certificate. 
A key object stores a cryptographic key and it further specialices in concrete 
types for the various cryptographic algorithms, such as RSA public and private 
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key. Cryptographic operations are performed in the context of sessions, which 
represent and established communication path with a token present in a slot. 

The Cryptoki API consists of a number of functions, encompassing slot and 
token management and object management, as well as cryptographic functions. 
Table 1 shows a significative set of these functions. 



3 Netscape and PKCS #11 



Netscape incorporates a security architecture that allows for web surfing and 
signed and encrypted e-mail. This security architecture, well-known as the “Netscape 
Security Library” (NSL), makes use of PKCS #11 cryptographic modules in 
order to offer the appropriate high level functionality. Netscape contains an in- 
ternal module PKCS #11 that constitutes a fairly complete implementation of 
the standard: it includes mechanisms based on RSA as well as some symmetrical 
key mechanisms. The internal module offers a logical vision of the computer as 
a cryptographic device: it uses the file system for persistent storage of Cryp- 
toki objects and the CPU for cryptographic processing. Thanks to this module, 
Netscape is able to offer the capabilities mentioned above, but it has a prob- 
lem: the use of the file system to store certificates and keys breaks the premise 
of safe storage of sensitive data. The solution adopted by Netscape is pass- 
word protecting data stored on disk and to allow the incorporation of external 
PKCS #11 modules, which then serve as specialized interfaces to cryptographic 
hardware, as in the case of our JCCM module. Another peculiarity of the NSL 
is that it allows the simultaneous presence of several PKCS #11 modules: our 
module can coexist with the internal module, and therefore it is not necessary 
to implement the mechanisms already supported; mechanisms oriented towards 
data encryption are not implemented (symmetric key) because the data transfer 
rate between the computer and the card makes it unsuitable for the encrypting 
arbitrary volumes of data. 

A trace of all the calls to our library needed to sign a mail from Netscape is 
shown below. The trace has been simplified and includes only the exit trace line 
for each Cryptoki functions called. 



— Lines 1 to 10: Library boot and initial data exchange. Lines 1 to 5, they are 
called when starting Netscape before we initiate any operation. Line 6, the 
token was present in the reader. Line 7, that obtains data about the token 
and its capabilities (lines 8 to 9). Finally, line 10, a session begins with the 
token. 



1 Mar 

2 Mar 

3 Mar 

4 Mar 

5 Mar 

6 Mar 

7 Mar 

8 Mar 

9 Mar 
10 Mar 



2 12:06:20 
2 12:06:20 
2 12:06:20 
2 12:06:20 
2 12:06:20 
2 12:06:21 
2 12:06:21 
2 12:06:21 
2 12:06:21 
2 12:06:21 



C_GetFunctionList Returns (CKR_0K) 0x0 
C_Initialize Returns (CKR_0K) 0x0 
C_GetInfo Returns (CKR_0K) 0x0 
C_GetSlotList Returns (CKR_0K) 0x0 
C_GetSlotList Returns (CKR_0K) 0x0 
C_GetSlotInf o Returns (CKR_0K) 0x0 
C_GetTokenInf o Returns (CKR_0K) 0x0 
C_GetMechanismList Returns (CKR_0K) 0x0 
C_GetMechanismList Returns (CKR_0K) 0x0 
C_0penSession Returns (CKR_0K) 0x0 
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Lines 11 to I 4 : 32 seconds are spent from line 10 to 11; they correspond to 
the time spent in writing the e-mail. These lines correspond to the request for 
the PIN and the corresponding call to C_Login() . The elapsed time between 
lines 13 and 14 correspond to the manual introduction of the PIN. 

11 Mar 2 12:06:53: C_GetSlotInf o Returns (CKR_0K) 0x0 

12 Mar 2 12:06:53: C_GetSessionInf o Returns (CKR_0K) 0x0 

13 Mar 2 12:06:53: C_GetSessionInf o Returns (CKR_0K) 0x0 

14 Mar 2 12:06:57: C_Login Returns (CKR_0K) 0x0 

Lines 15 to 66: The rest of the trace corresponds to the calls made by 
Netscape in order to generate a digital signature for a e-mail. The two last 
lines correspond to the signature. The time used for this operation (lines 65 
to 66) is only 2s, whereas the total time for the signature (lines 15 to 66) is 
26s. Those extra 24s are used in certificate searches and data transfer from 
the token. 



15 Mar 

16 Mar 

17 Mar 

18 Mar 

19 Mar 

20 Mar 

21 Mar 

22 Mar 

23 Mar 

24 Mar 

25 Mar 

26 Mar 

26 Mar 

27 Mar 

28 Mar 

29 Mar 

30 Mar 

31 Mar 

32 Mar 

33 Mar 

34 Mar 

35 Mar 

36 Mar 

37 Mar 

38 Mar 

39 Mar 

40 Mar 

41 Mar 

42 Mar 

43 Mar 

44 Mar 

45 Mar 

46 Mar 

47 Mar 

48 Mar 

49 Mar 

50 Mar 

51 Mar 

52 Mar 

53 Mar 



2 12:06:59: 

2 12:06:59: 
2 12:06:59: 
2 12:07:00: 
2 12:07:00: 
2 12:07:00: 
2 12:07:07: 
2 12:07:07: 
2 12:07:08: 
2 12:07:08: 
2 12:07:08: 
2 12:07:12: 
2 12:07:12: 
2 12:07:12: 
2 12:07:12: 
2 12:07:12: 
2 12:07:16: 
2 12:07:16: 
2 12:07:16: 
2 12:07:17: 
2 12:07:17: 
2 12:07:17: 
2 12:07:17: 
2 12:07:17: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:18: 
2 12:07:19: 
2 12:07:19: 
2 12:07:19: 
2 12:07:19: 
2 12:07:19: 
2 12:07:19: 



C_Find0bjectsInit Returns (CKR_0K) 0x0 

C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetMechanismList Returns (CKR_0K) 0x0 
C_GetMechanismList Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetSlotInf o Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_Find0bjectsInit Returns (CKR_0K) 0x0 
C_Find0bjects Returns (CKR_0K) 0x0 
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54 Mar 


2 


12:07:19: 


55 Mar 


2 


12:07:19: 


56 Mar 


2 


12:07:20: 


57 Mar 


2 


12:07:20: 


58 Mar 


2 


12:07:20: 


59 Mar 


2 


12:07:20: 


60 Mar 


2 


12:07:20: 


61 Mar 


2 


12:07:22: 


62 Mar 


2 


12:07:23: 


63 Mar 


2 


12:07:23: 


64 Mar 


2 


12:07:23: 


65 Mar 


2 


12:07:23: 


66 Mar 


2 


12:07:25: 


It is necessary to 



C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_FindObjectsInit Returns (CKR_0K) 0x0 
C_FindObjects Returns (CKR_0K) 0x0 
C_FindObjectsFinal Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetAttributeValue Returns (CKR_0K) 0x0 
C_GetSessionInf o Returns (CKR_0K) 0x0 
C_SignInit Returns (CKR_0K) 0x0 
C_Sign Returns (CKR_0K) 0x0 



that the certificate and the associated private key is used; the generation of a 
digital signature for the next and subsequent messages takes only 6s. 



4 Smart cards and Java Card 



Smart cards, besides being practical tamper-proof devices have ever-increasing 
computation and storage capabilities. They can be integrated in a natural way 
with the users’ applications, for instance a favourite browser, through the use of 
[PKCS#11]. 

Smartcards are present in a number of solutions on the market. Most of these 
solutions use the standard [PKCS#11] for certificate management, i.e., they 
provide the users with dynamic libraries that can be accessed by applications in 
order to handle security. The bad news is that these solutions ([SMARTSIGN], 
[GPKPKCS#!!], [SLBCBPKCS#!!]) tend to offer the applications a subset of 
PKCS #11 semantics, reduced to that provided by the smartcard manufacturer. 

Java Card is a reduced version of Java. In particular the virtual machine is 
very restricted. There is no garbage collector, and every object is instantiated 
in persistent memory until the end of the life-cycle of the “cardlet” (Java ap- 
plication running in a card). With respect to language, Java Card restricts the 
available packages and datatypes. The programmer has to deal with a simplified 
Object class, no String class, and only 16 bit integers. 

We have implemented our system in Java Card because this technology has 
several unique benefits: 

- Platform independence: this allows us to run our cardlet Cryptoki on differ- 
ent vendors’ cards. 

- Uses the Java language: which enables high programmer productivity and 
all the advantages of object-oriented programming. 

- Multi-application capable: multiple applications can run on a single card. 

- Compatible with Existing Smart Card Standards, such as IS07816. 
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5 JCCM: Java Card Certificate Management 

We have designed and implemented a system named Java Card Certificate Man- 
agement (JCCM). JCCM moves part of PKCS #11 code inside a Java Card. The 
JCCM cardlet is responsible for object management in conformance to Cryp- 
toki, implementing the corresponding Cryptoki functions. This is one of the key 
issues in the JCCM design: the cardlet handles management layer in Cryptoki 
objects, implementing the full management functionality defined in Cryptoki, 
that is: creation, lookup, copy and deletion of objects, and cryptographic func- 
tions. The set of cardlet Cryptoki APDU’s (Application Data Unit) is in Table 
2 . 



Table 2. Set of cardlet Cryptoki APDU’s 



General purpose 


Session management 


Ident 


DownLoadOb j Jnit 
DownLoadOb j _Attr 
DownLoadOb j .Create 
DownLoadOb j -Copy 
DownLoadObj _Set Attr 
DownLoadOb j -Find 
GetAttr 
DeleteObj 


Object management 


Login 

Logout 


Cryptographic 


Sign 



Another key issue in our design is the dynamic memory management in 
smartcards. EEPROM memory is the place where persistent objects live. It is a 
very limited resource and must be handled carefully. Cryptoki object manage- 
ment functions need to allocate and free memory, and we have implemented a 
simple memory management layer for this reason. This layer defines a spool of 
memory blocks that are to be marked used or free. The first two bytes of a mem- 
ory block contain a free/used bit and a 15-bit block length (2^^ Bytes=32KB), 
sufficient to include full available EEPROM in the current Java Cards. These im- 
plementation details are hidden from the calling functions. Memory management 
also merges small blocks into larger ones to avoid fragmentation. 

PKCS #11 represents objects as arrays of attributes. Attributes are fixed-size 
structures formed by three fields: attribute type, value pointer and the length of 
the value. A JCCM cardlet uses a similar scheme. An object structure is formed 
by three fields: 

— The “next object” pointer, 2 bytes. All the objects that are created in the 
card are maintained in a linked list. 

- Number of attributes of the object, 1 byte. This field can be deduced based 
on the size of the block in dynamic memory, but it has been chosen to 
include it: typically the card will store solely two objects, a certificate and a 
associated private key. 
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— A variable number of structures of attributes, so many as number of at- 
tributes has the object. 

An attribute object has the following fields: 

— Type of attribute, 4 bytes. It is the binary value defined in the standard. 

— An attribute pointer, 2 bytes. The value is stored in its own block of dynamic 
memory. The length of this field is obtained from the head of the block of 
dynamic memory in which it is stored. 




Fig. 1. Objects structure 



A Java class encapsulates each of these structures; the class ObjPatr for the 
objects and the class AttrPatr for the attributes. These classes cannot be instan- 
tiated due to the lack of garbage collection mentioned in the Section 4, they have 
only static methods and members. They are used to map the array of dynamic 
memory to the corresponding object structure: they also have methods to set/get 
the value of each field and to release the associated dynamic memory. These two 
classes extend the class Patr, that supplies basic access to fields of type multi- 
byte. Before using one of these classes to access a structure stored in dynamic 
memory it is necessary to establish the address of the structure by means of a 
call of set Addr (short addr), which sets the reference address used by all the 
methods that access the members of the structure (get ...(), set ...()). 

6 JCCM Implementation 

We have developed the corresponding dynamic library for Netscape that enables 
our final users to use JCCM in their security operations. The implementation 
has been done in Linux, using PC/SC Muscle and Netscape. We are porting now 
to Netscape for Microsoft Windows. 

To demonstrate device independence, we have ported JCCM to cards from 
two different manufacturers: Gemplus GemXpresso RAD 211is and Schlum- 
berger Cyberflex for Linux Starter’s Kit 2.1. The differences we found are 
twofold: the cryptographic capabilities are not standard in Java Card 2.0 (there 
were no Java Card 2.1 kits on the market when we begun to develop JCCM), 
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so we are forced to use proprietary hooks, and the way to load software differs 
between the cards. 

— GemXpresso RAD 211is [GemXpresso RAD 211 UG] uses Visa Open 
Platform for cardlet uploading. DES and 3DES are available, but not RSA. 
We need to transfer the private key to the computer to perform digital 
signing with RSA. 

— Cyberflex for Linux Starter’s Kit 2.1, [Cyberflex SDK] uses a propri- 
etary application (based on TCL/TK) for software loading. RSA via Schlum- 
berger’s extension javacardx. crypto. 

With respect to the cardlet itself, there are some differences; for example, 
the maximum size of the responses. The source code contains some compilation 
directives which adapt the code to the cards and it has to be precompiled to 
obtain java code that is then optimized for the card in question. A comparison of 
both cards is in Table 3. The size of the cardlet in the GemXpresso is much larger 
than in the Cyberflex, but in both cards there is room enough for storing up 
to 4 certificates (each certificate takes 1KB). GemXpresso is significantly faster 
storing and retrieving certificates (almost twice as fast as Cyberflex), perhaps 
because of better efficiency of the virtual machine implementation. 



Table 3. Cardlet comparison 



Card 


Size of Cardlet 


Storage (ms) 


Retrieval (ms) 




(Bytes) 


Private key 


Public key 


Certificate 


Certificate 


GemXpresso 


6437 


20312 


12998 


16228 


8934 


Cyberflex 


3992 


38122 


28180 


34036 


16155 
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Abstract. This article presents an analysis to statically check the Java 
Card sharing policy. From the program text, both the violation and the 
guaranty of correctness can be detected in certain cases avoiding Run- 
time exception. 

Using type inference techniques, a specific inference algorithm is pro- 
posed in order to achieve such result. The current implementation is 
outlined, and experimental results are given on a benchmark program. 

Keywords: Java Card, security, type inference, static analysis, objects 



1 Introduction 

Within the framework of increasing need for secured software, many systems 
are using sophisticated policies to ensure some level of security. Most of them 
involve dynamic checks, with de facto presence of dynamic errors and exceptions. 
In order to avoid the occurrence of such runtime errors, static analysis has to 
be used - to figure out, for instance, information on the calling graph, the heap 
structure, or alias information. Those forms of analysis require sophisticated and 
time consuming algorithms, which can make them rather ineffective on actual 
size programs. 

In this paper, we propose to use for the same purpose a rather simpler tech- 
nique: type inference- like algorithms for security checks. We experienced that 
idea on the Java Card security system. 

Java Card security policy is based on a firewall and a marker interface 
(Shareable). The firewall separates objects in different contexts: there is one 
context per package. Two objects belonging to two different contexts cannot ac- 
cess each other directly: the firewall in that case throws a dedicated exception 
(SecurityException). Method calls can only occur between contexts through 
Shareable interface. 

Our aim is to statically detect which accesses to objects may throw a Se- 
eurityExeeption in order to help the applet developer to improve his sharing 
mechanism and avoid such exceptions. The applet developer needs to provide 
the byte code of the set of applets he wants to analyse. Our context inference 
analysis will return the set of instructions which may throw a security exception. 



I. Attali and T. Jensen (Eds.): E-smart 2001, LNCS 2140, pp. 43-57, 2001. 
© Springer- Verlag Berlin Heidelberg 2001 



44 



Denis Caromel et al. 



Then, the developer will know which parts of his program have to be improved 
in order to avoid this kind of exceptions. 

This paper presents a context inference method to analyse the sharing of 
objects. The basic idea is to define an abstract context as the set of all possible 
creation contexts of an object. Then we apply a type-inference like and a type- 
checking like mechanism, considering abstract context as a type. For example, 
a call statement o . f oo (...) is guaranteed to be correct only if type of o is a 
sub-interface of Shareable or if the potential context of o is unique and identical 
to the context of execution. 

The current inference system is defined on a large and representative subset 
of the Java Card Bytecode. With minor modifications, the system could as well 
be directly specified and implemented on the Java Card source code. 

Section 2 presents the JavaCard security policy and related work on static 
analysis and type inference. Section 3 presents the object sharing analysis. In 
section 4, we briefly describe an implementation of the analysis, and experimental 
results on a benchmark program. 

2 Context and Related Work 

2.1 Java Card, Sharing, and Security 

The Java Card language is a restriction of the Java language described in [1], [13] 
and [16]. In this section we present the Java Card security policy and a reduced 
set of bytcodes on which the analysis will be described. 

Java Card application are called Applets. The Java Card Runtime Environ- 
ment (JCRE) is the operating system of the card ([14]). 



Java Card Security The Java Card firewall is described in the section 6 
of [14]. Some Java Card security limitations and how to improve it are presented 
in [5], [6] and [8]. The main principles of Java Card firewall are described below. 

The Java Card firewall partition the set of existing objects into contexts. 
A context is associated to each applet when it is installed. There is one context 
per package so two applets declared in the same package won’t be separated 
by the firewall. The JCRE belongs to its own context. At any point, there is a 
currently active context. Each object belongs to a context which is the context 
which was active when the object has been created. A context switch occurs 
when executing certain method invocations. When a bytecode accesses an object 
(field access, cast or method invocation), a runtime check is performed and if 
the access is refused then a SecurityException is thrown. 

An access to an object is allowed if the current execution context is the same 
as the object context, that is to say an object can only be accessed by its owning 
context except in the cases below. 

Static fields and methods do not belong to any context and can be accessed 
from any context. 
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The JCRE can access to objects in every context. The JCRE can specify 
objects as entry points, their methods are accessible from any context. In the 
same way, fields of global arrays are accessible from any context. 

In order to allow the dialog between two applets. Shareable interfaces have 
been defined. An interface is Shareable if it extends the interface Shareable. 
A method can be invoked through a Shareable interface even if the object context 
is different from the current context. 

When a non-static method is invoked, and the call is authorised, the VM 
performs a context switch if necessary that is to say the current context is 
switched to the context of the object of the invoked method. 

Bytecode Subset We present a subset of Java Card bytecode that is sufficient 
for understanding and designing the analysis. The whole bytecodes are described 
in [15] 

aload i pushes the local variable on the operand stack; 
astore i pops an element of the stack and writes it in the local variable; 
getfield f pushes on the operand stack the field / of an object popped from the 
stack; 

putfield f pops a value and an object from the stack and writes the value in 
the field / of the object; 

new A allocates a new instance of the class A and puts the new reference on 
the stack; 

invokeVirtual M calls method M M is a reference to the method correspond- 
ing to the static type of the object accessed; 
invokeStatic M calls the static method M; 
invokeShareable M calls method M on a shareable interface; 
return returns the top of the stack from a method. 

invokeShareable does not correspond to any Java Card bytecode but we 
can statically classify invoke Interface commands into the invokeShareable 
instructions and the others which can be considered as invokeVirtual for our 
analysis. Indeed, we determine statically if an invoke Interface command con- 
cerns a Shareable interface or not. 

Our analysis is based on bytecode because ambiguities (name resolution) are 
removed during compilation. Moreover, since the JVM is the target of several 
languages (see [17] for a complete list of such languages), our analysis may be 
applied independently of the source language. 

If we wanted to apply our analysis on Java Card language, we would have to 
resolve all these ambiguities and most of the analysis would be redundant with 
the compilation phase. In fact the context analysis would be translated easily 
but we would need to extend our analysis with aspects that are independent 
from Java Card sharing mechanism. 
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2.2 Static Analysis Techniques 

The firewall characteristics brought us to think about static analysis techniques 
because firewall analysis could be rewritten in terms of aliasing between contexts 
which could be analysed like [2,3,4,10,11]. But such analysis are very difficult to 
implement especially because we need a precise interprocedural analysis (cf. [12]) 
and both may and must-aliasing properties must be computed if we want to give 
precise results to the developer. 

Our analysis infers a set of possible creation contexts for each object. The 
context inference is similar to set constraints [7] but constraints solving is much 
simpler because abstract contexts does not contain function symbols. Indeed 
function symbols are used in [7] to introduce more complex constraints and are 
not necessary in our analysis. 

2.3 Java Card Exceptions 

The LOOP project (see for example [9]) developed a tool to specify pre- and 
post-conditions for Java methods. It provides static verification that a program 
will not throw certain kind of exception. Our aim is to provide a mechanism 
dedicated to object sharing and to ensure that a program will not throw a 
security exceptions with a static analysis. Moreover, an important contribution 
of our analysis is to provide context inference for Java Card programs. In our 
case, the developer do not have any information to specify nor source code 
annotation to write. 

3 Sharing Analysis 

3.1 Aim and Principles of the Analysis 

The aim of the analysis is to determine if an access to an object may throw a 
security exception or not. So, we have to compare, for each access to an object 
(field access, field update or method invocation), the creation context of this 
object and the execution context of the instruction we are analysing. Statically, 
we infer a set of possible creation contexts (abstract context) for every location 
containing objects. We suppose that the analysed bytecode is correct that is to 
say, a program that would be rejected by the type checker can not be analysed. 

3.2 Overview of the Analysis 

In order to make context inference, we extract from the bytecode of the program 
a set of inequations. These inequations represent the dependencies between Ab- 
stract Contexts (AC) and are obtained from data dependencies by adding re- 
lations between contexts, for example between current method context and the 
context of an allocated object upon a new instruction. 
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We need to define temporary variables named ACVariahle to denote locations 
before an AC has been inferred. 

M G Methods 

T G ACV ariahle ::= M.Local[i] \ M. Return \ label \ ACVariahle. field 

Where M.Loeal[i] is the ACVariahle denoting the abstract contexts of the i^^ 
local variable of method M. M. Return is an ACVariahle corresponding to the 
object returned by method M. label is a variable corresponding to an object 
allocation bytecode (we write {new There should be a unique label for 

each new instruction. ACVariahle. field denotes the AC of the field field of the 
objects corresponding to ACVariahle. 

The analysis determines an AC for every ACVariahle which has been created. 
Then, for each object access bytecode, we compare object’s AC set with the set 
of possible execution contexts to find instructions which may throw a security 
exception. 

The analysis consists of five steps: 

1. Establish dataflow information from the bytecode. Here we obtain a partial 
dataflow graph which does not take into account possible aliases between 
objects. 

2. Add dataflow dependencies due to possible aliases. After this step, we must 
obtain a relation x^py which can be read as “every value stored in x can 
be stored in y” . 

3. Create context flow graph from the dependence graph. This step consists in 
adding to dataflow some context dependencies specific to Java Card security 
policy (e.g. the context of an object is the context of the method which 
instantiates it). 

4. Infer an abstract context for each location representing an object. That 
means And the smallest solution of constraints expressed by the context 
flow graph. 

5. Abstractly execute the bytecode to determine which object accesses may 
throw a security exception or not. 

Alike a control flow insensitive algorithm, the context inference presented 
here does not take into account the order of instructions. In fact order of in- 
structions are only useful to determine the abstract execution stack. This could 
be improved by other techniques like aliasing [2] or shape analysis [11] which 
would generally be more complicated and slower. Our analysis is based on type 
inference like algorithm. The dataflow information obtained here is sufflcient in 
order to make type inference (they could be seen as some kind of type con- 
straints). Then, the abstract context obtained could be considered as a type. 

3.3 Abstract Stack 

In table 1, we describe the action of each bytecode instruction on the abstract 
stack. The stack is represented by a list of ACVariables. In the following, CM is 
the method currently analysed. 
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Table 1. Abstract execution of bytecode 



aload i\- S ^ CM.Local[i] :: S (1) 

astore i \~ T :: S ^ S (2) 
getfield f \~ T :: S ^ T.f :: S (3) 
putfield f \-Ty ::T :: S ^ S (4) 

{new A)^ \- S :: S (5) 

invokeVirtual Mq h Tq :: S' ^ Mq. Return :: S (6) 

invokeStatie Mq h Tq :: S ^ Mq. Return :: S (7) 

invokeShareable Mq \~ Tk Tq :: S ^ Mq. Return :: S (8) 

Return \~ T :: S ^ S (9) 



The signature of the abstract stack definition rules is : 

Instruction h ACVariable"^ ACVariable"^ 

For instance ins \~ si ^ S 2 means that the abstract execution of ins on the 
abstract stack si produces the abstract stack S 2 - 

3.4 Dataflow Analysis 

In order to make a sharing analysis, we first need dataflow information to be 
able to infer an AC. We compute a dataflow graph from source bytecode, 
is the dataflow dependence relation. It is a transitive relation on ACVariable. 
must be read as every value stored in x can be stored in y. 

The rules presented in table 2 describe how a set of dependence constraints 
can be extracted from the program source. Every affectation (explicit or implicit) 
is interpreted as a dataflow constraint. 

In order to take into account the dynamic binding without analysing the 
possible types of each variable, we added a relation M < M' defined in rules 17 
and 18 which is the reflexive extension of the overloading relationship. Then 
every invocation of a method M' can dynamically invoke the method M. This 
implies the data flow dependencies expressed in the rules 12, 14 and 15. 



3.5 Aliasing 

The relation we have obtained with the rules above does not really correspond to 
a complete dataflow dependence relation. Indeed, some aliases between references 
may cause additional dataflow edges. If two locations may reference the same 
object then any object modifications on one location may act on the other. That 
is why we define the alias relation on ACVariable. 
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Table 2. Data flow rules 



Rules related to affectations: 



astore i\~ T :: S ^ S 



(10) 



T — >pC M. Local \i 
putfield f \-Ty ::T :: S ^ S 



( 11 ) 



n^FT.f 

invokeVirtual M h :: .. :: To :: S ^ S' A Mo < M 
Vi G 0 ... /c, Ti^FMo.Local[i] 
invokeStatic M \~ Tk :: .. :: To :: S ^ S' 



( 12 ) 



(13) 



Vi G 0 ... /c, Ti-^FM.Local[i\ 
invokes har cable M \~ Tk :: .. :: To :: S' ^ 5" A Mo < M 



Vi G 0 ... /c, Ti^FMo.Local[i] 
Return \~ T :: S ^ S' A CM < M 



T^f M. Return 



(15) 



(14) 



Transitivity: 



T^fT" 



(16) 



Method overloading: 



Method2 redefines Methodl 
Method2 < Methodl 
M <M (18) 



(17) 



The table 3 defines an alias relation and the influence of aliasing on 
dataflow graph, is a reflexive relation. It determines whether two ACVari- 
ahle may represent references which may be aliased. The rules 19 and 20 corre- 
sponds to this definition of aliasing. Moreover field access expressions of aliased 
variables are aliased (21). The last rule (22) correspond to effects of aliases on 
dataflow: if two objects are aliased then a field update on one object may update 
the other one. 
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Table 3. Aliasing 



T^fT' a T^fT" 


(19) 


T'^aT" 


data flow ^ aliasing 




T^fT' 

; (20) 

T^aT' 




alias => fields alias 




T^aT' 

(21) 

T.x^aT'.x 




Alias acts upon field update: 




T^aT' a T"^fT.x 


(22) 


T"^fT'.x 



3.6 Context Flow 

Given a dataflow graph, we need to add context information to infer abstract 
contexts. We define Context Variables 

V G ContextVariable ::= T \ M.CC \ (T H M.CC) \ Package 

Where M.CC represent the execution context (current context) of methodM. 
Dynamically, the current context can be included in the current frame properties. 
A new frame is created when a method is invoked. As we decided to have one 
AC for each variable of the program, we only need to have an abstract current 
context by method. 

The table 4 presents the specification of context additional properties. Con- 
text flow(Ec) is obtained from data flow by adding creation context and context 
switch information. In our simplified bytecode, context switch can occur only 
if a shareable interface method is called. Then, we obtain a context flow graph 
which express constraints between ACVariahle due to dataflow or context de- 
pendencies. Ec is a transitive relation between Context Variables, x [Zc y must 
be read as abstract context of x is included in abstract context of y. 
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Table 4. Context flow 



dataflow ^ context inclusion ^ 

1 —>Fi 



T\ZcT' 



(23) 



Object creation context: 



(newCfhS^T-.-.S 

(24) 

CM.CC Cc T 



Applet context: 



applet A is defined in package Package A 
M corresponds to install, process, (de) select or 

getShareableInterfaceObject (^5) 

Package \Zc M.CC 



Current context propagation for method invocation: 



invokeV irtual Mq \- Tk Tq :: S ^ Mq. Return :: S 
(Ton CM.CC) Ec Mo.CC 
invokeStatic Mq h Tfc To :: S' ^ Mq. Return :: S 



(26) 



CM.CC Cc Mo.CC 

invokeShar cable Moint h T^ To :: S' ■ 



(27) 



Mo -Return :: S 



To Cc Mo.CC 



(28) 



Transitivity: 



Vi Cc V 2 A 1^2 Cc Vs 



V Cc Vs 



(29) 



Context intersection : 



P\ZcVi A PHc V2 

(30) 

p Oc (Vi n V2) 



The rule 25 initialises the context of applet specific methods with their def- 
inition package. This corresponds to the fact that the JCRE instantiates and 
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activates an applet in a context corresponding to the package of applet defini- 
tion. 

The rule 26 could be simplified by only requiring CM.CC Ec Mq.CC or 
To Ec Mq.CC which would be correct but less precise. It is the role of the type 
checker to verify that Tq = CM.CC. Thus requiring (Tq fl CM.CC) Ec Mq.CC 
is only useful when the sharing checking can not determine whether an exception 
could be raised by the invokeVirtual statement or not. In this case, we consider 
in the rest of the analysis that no exception has been raised by this method 
invocation. 

3.7 Context Inference 

Context inference consists in determining an AC for each Context Variable. From 
the context flow graph, the AC of a ContextVariable V is given by the set of all 
packages P such that P \ZcV. Leaves of context flow graph should be packages. 
We can not infer contexts from other kind of leaves which would correspond for 
example to instructions which would never be executed. An AC is a set of type 
Packages. 



AC ::= Package"" 

C : ContextVariable AC 
C {Package) = {Package} 

C{V) = U ^ 

P\ZcV 



C{V) is the AC inferred for the ContextVariable V. It gives the smallest set 
verifying the constraints expressed in the context flow graph. 



3.8 Sharing Checking 

This step looks like a type checking phase. It classifies the accesses to the object 
in three categories: 

— The instructions that will never throw a security exception. This case occurs 
when: 

• both execution and object accessed contexts are identical singletons. 

• the instruction is a method invocation on a shareable interface or a JCRE 
entry point. 

— The instructions that may throw a security exception: intersection of execu- 
tion and object accessed contexts is non empty. 

— The instructions that will always throw a security exception: intersection of 
execution and object accessed contexts is empty. 

This step consists of an abstract execution of each instruction of the programs. It 
behaves like a classical type checker but returns a classification of the instructions 
accessing to objects (getf ield, putf ield, invokeVirtual) in accordance with 
the categories defined above and the security policy of the Java Card firewall. 
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3.9 Sharing Analysis of Java Card Programs 

In order to analyse real Java Card programs within our implementation, the 
most important characteristics that have been added to the analysis formally 
presented above are the following. 

Manipulations of simple data do not generate constraints but we need to 
have an AC Variable to represent them in the stack. One AC Variable for every 
simple type constant and variables is sufficient. 

As for Arrays, they are abstracted by a unique variable. That is sufficient 
when all elements belong to the same context. 

For conditional branches we need to make a union of abstract stacks at each 
junction point. In order to do this, we only replace abstract stack at this point by 
an abstract stack composed of new ACVariable and add new dataflow relations 
between abstract values before the junction and ACVariable at the junction. 

Exceptions have not been implemented at all in our analysis. As our analysis 
is insensitive to control flow, analysing exception would be simple. Indeed the 
point where the exception can be thrown is not important for our analysis. 

4 Implementation, Performance, and Results 

4.1 The Cap Tool Framework 

The Cap Tool (figure 1) is a tool taking cap flies (Java Card bytecode) and 
returning a structured and linked program. It provides visualisation of the byte- 
code of each method and a bytecode interpreter. We use this linked version 
of bytecode to implement our analysis. We have implemented a simple sharing 
analysis on the bytecode language except exception handling. The results of the 
analysis are integrated to the bytecode as comments. Every instruction accessing 
to object is annotated with OK if it is sure, ??? if an exception may be thrown 
or ERROR if the access will always throw a security exception. 



4.2 Examples of Results 

Eigure 2 gives an example to illustrate the sharing analysis mechanism. It de- 
fines two applets, a class A and its shareable interface. These applets have been 
analysed by our type inference mechanism. The results of the analysis have been 
inserted in the code comments. Eigure 1 shows the results of the analysis of 
method appletO .process. 

In figure 2, there are 4 instructions accessing to objects. In instruction 
an object can be instantiated in two different contexts and the result is con- 
trol flow dependant. It is impossible to determine whether an exception will be 
thrown or not. In instruction our analysis can not infer that aa is always 

instantiated in the calling context. A more precise version of our analysis, for 
example control flow dependant analysis or an analysis which would analyse a 
method twice if it is executed in two different contexts could improve this result. 
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Fig. 1. The Cap Tool and partial results of the analysis 

The Bytecode is a part of the method process of class AppletO of figure 2 



In instruction **3** the object is accessed in his creation context. And in in- 
struction **4** it is accessed through a shareable interface. In these two cases 
our analysis verify that no security exception will be thrown. 

This example shows some interesting cases and limitations of our analysis. 
A lot of cases where our analysis can not determine whether a security exception 
can be raised or not could only be improved by taking into account the control 
flow corresponding to the program. For example we could greatly improve our 
analysis by duplicating the bytecode of some functions and analysing it twice de- 
pending on the execution context. Such a solution is in fact a mean of improving 
the interprocedural analysis. 





Context Inference for Static Analysis of Java Card Object Sharing 



55 



package appletO; 

import javacard. framework.*; 

public interface Ashare 
extends Shareablet 

public void fO(byte e) ; 

} 



(a) A Share .java 



package appletO; 

public class A implements Asharet 
public A aa; 
public A() { 
aa=this ; 

} 

public void fO(byte e){ 

} 



package appletO; 

import javacard. framework. * ; 

public class appletO 
extends Applet { 

public static A a; 

public static Ashare shareA; 

public static void install (A aO) { 
a=new A() ; 
share A=new A(); 



public void process () { 

a. f0( (byte)O) ; // **1** 

// a may be instantiated 
// by applet 1 -> ??? 

(new AO) .aa.f0((byte)0) ;//**2** 
// aa can be modified in 
// constructor A which can be 
// called from appletl -> ??? 

} 

} 



(c) AppletO. java. 



(b) A. java 

package appletl; 

import javacard. framework. * ; 

import appletO.*; 

public class appletl 
extends Applet { 

public static void install () { 

A b=new A() ; 

// b is instantiated in 
// the context of appletl 
b.aa=applet0.a; //**3** 

// acces to b in the 
// context of appletl -> OK 
(new appletl ()) .process 0 ; 

} 

public void process () { 

appletO . a=new A(); 

// can change the 
// context of field a 
// of appletO 

appletO . shareA . f 0 ( (byte) 3) ; //**4** 
// access to shareable 
//interface -> OK 

} 

} 



(d) Appletl. java 

Fig. 2. Example of analysed code 



5 Conclusion 

We have presented a sharing analysis for Java Card language. It is based on a 
type inference like analysis. Indeed contexts could be considered as some kind 
of types and a security exception as an incompatibility between such types. Our 
analysis abstracts the dynamic context by a set of possible contexts. It is based 
on the Java Card bytecode but could be implemented on Java Card language as 
well. 

Our objective is to help the developer to design complex sharing mechanisms. 
We provide him the list of instructions that may throw a security exception. The 
developer will only have to focus on these instructions in order to determine 
whether they may really throw a security exception or not. Moreover, we give 
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him the set of possible creation contexts for each variable and the set of possible 
execution contexts for each method of the analysed applets. 

In order to improve our analysis, we can duplicate some method. For example, 
we could create an instance of a method for each possible execution context. This 
would make us analyse more functions but could greatly improve the precision 
of our analysis on some crucial locations. 



References 

1. Zhiqun Chen. How to write a java card applet: A developer’s guide. 

ht t p : / / WWW . j avawor Id . com / j avawor Id / jw-07-1999/jw-07-j avacar d _p . ht ml . 44 

2. A. Deutsch. Interprocedural may-alias analysis for pointers: Beyond /c-limiting. In 
SIGPLAN’94 Conf. on Programming Language Design and Implementation^ pages 
230-241, Orlando (Florida, USA), June 1994. ACM. SIGPLAN Notices, 29(6). 46, 
47 

3. Alain Deutsch. A storeless model of aliasing and its abstractions using finite repre- 
sentations of right-regular equivalence relations. In Proeeedings of the IEEE 1992 
International Conferenee on Computer Languages^ pages 2-13, San Francisco, April 
1992. IEEE Press. 46 

4. Alain Deutsch. Semantic models and abstract interpretation techniques for induc- 
tive data structures and pointers. In Proeeedings of the ACM SICPLAN Sym- 
posium on Partial Evaluation and Semanties- Based Program Manipulation, pages 
226-229, La Jolla, California, June 21-23, 1995. 46 

5. Anup K. Ghosh. Security risks of java cards. In Proeeedings of the Twelfth IPIP 
WG 11.3 Working Conferenee on Database Seeurity, Greece, 1999. 44 

6. Pierre Girard. Which security policy for multiapplication smart cards. In Pro- 
ceedings of the USENIX Workshop on Smarteard Technology (SMARTCARD-99), 
pages 21-28, Berkeley, CA, May 10-11 1999. USENIX Association. 44 

7. Nevin Heintze. Set constraints in program analysis. Technical report, Carnegie- 
Mellon University, July 1993. 46 

8. Michael Montgomery and Ksheerabdhi Krishna. Secure object sharing in java 
card. In Proceedings of the USENIX Workshop on Smarteard Technology 
(SMARTCARD-99), pages 119-128, Berkeley, CA, May 10-11 1999. USENIX As- 
sociation. 44 

9. Erik Poll, Joachim van den Berg, and Bart Jacobs. Specification of the JavaCard 
API in JML. In Eourth Smart Card Research and Advanced Application Conference 
(IE IP Cardis). Kluwer Academic Publishers, 2000. 46 

10. M. Sagiv, T. Reps, and S. Horwitz. Precise interprocedural dataflow analysis 
with applications to constant propagation. Lecture Notes in Computer Science, 
915:651-??, 1995. 46 

11. Mooly Sagiv, Thomas Reps, and Reinhard Wilhelm. Parametric shape analysis 
via 3- valued logic. Technical Report CS-TR- 1998- 1383, University of Wisconsin, 
Madison, August 1998. 46, 47 

12. M. Sharir and A. Pnueli. Two approaches to interprocedural data flow analysis. 
1981. 46 

13. SUN microsystems. Java card 2.1 platform api specification, 
http : / /j ava.sun.com /products/j avacard /htmldoc / index.html. 44 

14. SUN microsystems. Java card 2.1 runtime environment (jcre) specification. 
http://java.sun.com/products/javacard/JGRESpec.pdf. 44 



Context Inference for Static Analysis of Java Card Object Sharing 



57 



15. SUN microsystems. Java card 2.1 virtual machine specification. 
http://java.sun.com/products/javacard/javacard21.html. 45 

16. SUN microsystems. Java card applet developper’s guide. 

http: / /java.sun.com/products/javacard/AppletDevelopersGuide.html. 44 

17. Robert Tolksdorf. Programming languages for the java virtual machine. 
http://grunge.cs.tu-berlin.de/ t oik/ vmlanguages.html. 45 



58 



Automated Test and Oracle Generation 
for Smart-Card Applications* 



Duncan Clarke, Thierry Jeron, Vlad Rusu and Elena Zinovieva 
{ dclarke | j eron | rusu | lenaz } @irisa. fr 

IRISA/INRIA Rennes, Campus de Beaulieu, Rennes, France 



Abstract. We present work we are engaged in to develop symbolic test 
generation techniques and apply those techniques to testing of smart 
card applications. Beginning with (1) a system specification and (2) a 
test purpose expressed as symbolic labelled-transition-systems, we auto- 
matically derive tests to check conformance of an implementation to the 
behaviors of the specification selected by the test purpose. We present 
an example taken from a case-study we are developing based on the 
application of these techniques to the CEPS e-purse specifications. 



1 Introduction 

After decades of research into techniques for formal system specification, 
test generation, notions of test coverage, and methods for automating the 
evaluation of test results, the practice of software testing remains largely 
unchanged for most software developers. A developer familiar with the 
informal requirements for an application designs test cases in an ad-hoc 
fashion, runs those tests against an implementation, and compares the 
outputs of the implementation to his or her intuition regarding what the 
requirements dictate for the associated test case. Human-centric testing 
methodologies like this (1) are prone to error, (2) make poor use of existing 
formal specifications, and (3) make poor use of human resources. 

Indeed, researchers and developers working in some specific problem 
domains have noted these facts, and taken steps to establish develop- 
ment methods with a sound formal basis that are open to automation. 
One of the most successful such efforts to date is in specification and 
conformance testing of protocols [IS092]. In protocol specification and 
conformance testing a formal model of the protocol is created using a well- 
defined formalism with a sound mathematical basis such as SDL [IT94] 
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or LOTOS [IS088], a conformance criterion [Tre94] is defined to establish 
exactly what it means for an implementation to conform to its specifica- 
tion, and a set of tests can be generated that have the ability to check 
conformance by driving a system under test through a desired sequence 
of states and comparing replies received to expected values. These tech- 
niques are developed to the point that several tools for the automatic cre- 
ation of such test suites are available, including TorX [BFdV"^99], TGV 
[JM99] and Test Composer [KJG99]. 

Our work is an attempt to leverage the ideas underlying protocol con- 
formance testing and high-efficiency test generation as embodied in the 
TGV tool, to automate the generation of tests for a more general class 
of applications. TGV, like most existing formal analysis tools, performs 
its analysis by enumerating the specification’s state space. This leads to 
two significant problems when generating tests for large-scale systems: (1) 
state space explosion, as the variables in the specification are instantiated 
with all of their possible values, and (2) tests that are not readily under- 
standable by humans when represented by a large network of states and 
transitions in a pure labelled transition system. To avoid these problems 
we are applying symbolic techniques to perform our analysis. 

In [RdBJOO] the authors presented a method for the generation of 
symbolic test cases from system specifications and test purposes expressed 
in the Input/Output Symbolic Transition System (lOSTS) formalism. 
The models used are symbolic in the sense that items represented by 
variables over data domains in the control and computation steps of the 
specification remain variables in the generated tests. At no point in the 
analysis is it necessary to enumerate the state space of the specifications, 
test purposes or generated tests. 

In addition to the elimination of the need for state space enumeration, 
the principal benefits of this approach are four- fold: (1) The derivation 
of tests and oracles from formal, operational specifications can be fully 
automated; (2) The tests are symbolic in the variables and parameters 
of the specification, so a single test can be generated and applied to 
implementations based on different specification parameter values; (3) 
The resulting tests are concrete, in the sense that once parameters are 
instantiated the tests can be translated easily to a test language and 
applied directly to real implementations (provided the model and the 
system under test are compatible at the interface level); and (4) the theory 
underlying the derivation of tests guarantees certain desirable properties. 
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such as correctness and completeness of verdicts relative to the given test 
purpose. 

Recent work by Martin and du Bousquet shares our goal of automation 
of test generation for smart-card applications. In [MdBOO] they describe 
a testing methodology for smart card applications based on UML spec- 
ifications, the use of TGV for on-the-fiy test generation, and translation 
of TGV-generated tests to Java code for the creation of executable tests. 
There are three important points of contrast between their approach and 
ours: (1) They present their work using high-level UML specification mod- 
els; at present our methods are based on the low-level lOSTS formalism, 
which will ultimately be used as an intermediate representation format. 
(2) The use of TGV for test generation introduces a risk of state space 
explosion if there are large data domains for inputs of the tester; the 
technique we describe is all symbolic, so there is no risk of state space 
explosion. And (3), TGV requires parameter values to be bound to in- 
dividual values before test generation; the technique we describe allows 
system parameters to be bound to values as late as test execution time. 

The remainder of this paper is structured as follows: Section 2 briefiy 
describes the lOSTS formalism and an overview of symbolic test genera- 
tion. Section 3 presents a brief example demonstrating the application of 
symbolic test generation to one feature described in the CEPS [CEPOO] 
e-purse specifications. Section 4 describes the tool we are developing to 
automate symbolic test generation from formal specifications down to 
executable C++ test code. Section 5 closes the paper with summary re- 
marks. 

2 Symbolic Test Generation 

Test generation is a program-synthesis problem: starting from the formal 
specification of a system under test and from a test purpose describing a 
set of behaviors to be tested, compute a reactive program that observes an 
implementation of the system to detect non- conformant behavior, while 
trying to control the implementation towards satisfying the test purpose. 
In this section we briefiy describe our approach [RdBJOO] for generating 
symbolic test cases in the form of extended input-output automata. 

The model. lOSTS (Input-Output Symbolic Transition Systems) are a 
model for reactive programs with symbolic processing of variables, param- 
eters, and inter-process value passing. Several examples of lOSTS are 




Automated Test and Oracle Generation for Smart-Card Applications 61 



given in the figures of Section 3. The syntax and semantics are formal- 
ly defined in [RdBJOO]. We use lOSTS for describing specifications, test 
purposes, and test cases, and assume nothing about the black-box imple- 
mentation other than that it is interface-compatible with the specifica- 
tion. Furthermore, we restrict our attention here to specifications and 
implementations that are command-response^ meaning that an input, or 
sequence of inputs, may only be followed by at most one output (i.e., a 
command is followed by at most one response), and there are no infinite 
loops of internal actions. 

The 10 STS notation is rather low-level and is mainly convenient for 
processing by machine as done in symbolic test generation. For specifying 
systems at the user level, we plan to use a higher-level language which 
translates automatically to lOSTS (cf. Figure 1). The part of the diagram 
within the dashed box corresponds to the current status of the test gen- 
eration tool. We also plan to incorporate mechanisms to automatically 
compute test purposes from, e.g., coverage criteria [RW85]. 




Test Result: 

Pass, Fail, Inconclusive 



Fig. 1. Symbolic Test Generation Process. 
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The process. Symbolic test generation consists in computing, from spec- 
ification and test purpose, a test case that covers all the behaviors of 
the intersection of these two elements. Then, the test case is translated 
into executable code to be run on the black-box implementation. Test 
generation consists of the following steps. 

— product between test purpose and specification. This allows the selec- 
tion of a subgraph of the specification that formally leads to the sat- 
isfaction of the test purpose. That is, only the subgraph leading to 
accepting states of the test purpose is kept. Here “formally” refers 
to the fact that symbolic variables and parameters are not interpret- 
ed, thus, actual reachability of the accepting states is not guaranteed. 
This problem is addressed in the simplification step. 

— closure and determinization of the product. This operation attempts, 
through a set of heuristics, to produce a trace-equivalent system that 
has no (or fewer) internal actions and is deterministic. The heuris- 
tics will successfully terminate when applied to command-response 
systems. 

— adding verdicts. This step consists in labeling some states with ver- 
dicts. “Pass” means that the test purpose was satisfied and no errors 
were detected (i.e., there were no observable differences between im- 
plementation and specification). “Inconclusive” means that, although 
no errors were detected, uncontrollable behavior has lead the test exe- 
cution to a point where the test purpose cannot be satisfied any more. 
“Fail” means that an error was detected. 

— simplification. At the end of the previous step, we have an lOSTS test 
case that is ready to be translated into a programming language. How- 
ever, since there are potentially unreachable parts in the test case, we 
attempt to prune infeasible transitions by statically evaluating their 
guards using the Omega library [KMP"^]. The guards are analyzed 
to determine whether there is any valuation of variables that could 
satisfy the guard at run-time. If not the transition is removed along 
with any locations and transitions thereby made unreachable. This 
step is not mandatory, however, it may significantly reduce the size of 
the executable test case. 

— translation to C++. This final step builds a C++ program from the 
lOSTS test case obtained after all previous steps. The Omega library 
[KMP+] is called whenever there is a need to compute values to in- 
stantiate a symbolic output. The program is then ready to be compiled 
and linked with the implementation for test case execution. 
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Correctness of test cases. In [RdBJOO] we prove that the generated lOSTS 
test cases have, by construction, a set of correctness properties, meaning 
essentially that they do not produce false “Pass” , “Fail” and “Inconclu- 
sive” verdicts. Furthermore, every test case generated from a given spec- 
ification and test purpose has a relative completeness property, meaning 
that a “Fail” verdict will be produced in every circumstance where the 
implementation exhibits a non-conformance with the specification in a 
behavior targeted by the test purpose. 



3 Example 

In this section we present a brief example of symbolic test generation 
based on a feature of the CEPS e-purse specifications. CEPS (Common 
Electronic Purse Specifications) is a standard for creating inter-operable 
multi-currency smart card e-purse systems. The feature that we will gen- 
erate tests for is the “CEP Inquiry - Slot Information” specified in Sec- 
tion 8.7.1 of the CEPS technical specifications [CEPOO]. This feature pro- 
vides a means for iterating through the slots, where each slot corresponds 
to one currency and its respective balance. The number of currency slots 
in the purse is implementation dependent, and the number of slots act- 
ually loaded with currency can vary during use, so a generic iteration 
scheme is provided for viewing each slot in turn. The specification requires 
that each currency be returned exactly once followed by an end-of-data 
marker. The order in which currencies are returned is unspecified and 
implementation dependent. 

As described in Section 2, the process of test generation consists of 
(1) creating an lOSTS specification, (2) creating an lOSTS test purpose, 
and (3) generating an lOSTS test. We begin with the specification. 

The specifications. Figure 2 presents the part of the lOSTS model of the 
CEPS specifications that describes iterative extraction of slot informa- 
tion from the card’s point of view. The lOSTS is made up of locations 
and transitions. Transitions are decorated with their guard expressions, 
their input or output action (preceded by a “sync” keyword), and their 
assignments (using the notation for assignment). A transition is 

firable when its guard is satisfied and a complementary action is offered 
by the environment for synchronization. Transitions labelled with action 
“tau” are internal actions that can fire without synchronizing with the 
environment. 
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mType = FirstSlot 
CepInquiry?(mType) 
vSlotIndex := 0 
vSlotsReported := 0 



vSlotIndex < pSlotCount ^ not vSlots[vSlotIndex].InUse 
sync tan f 

vSlots [vSlotIndex] .Reported := true ^ 
vSlotIndex := vSlotIndex + 1 
vSlotsReported := vSlotsReported + 1 





mType = FirstSlot 
sync CepInquiry?(mType) 
vSlotIndex := 0 
vSlotsReported := 0 



vSlotIndex < pSlotCount ^ vSlots[vSlotIndex].InUse 
sync tan 

vSlots[vSlotIndex] .Reported := false 
vSlotIndex := vSlotIndex + 1 



vSlotIndex = pSlotCount 
sync tan 



mStatus = Normal ^ vSlotsReported < pSlotCount ^ 
mSlot.Index >= 0 ^ mSlot.Index < pSlotCount ^ 
(not vSlots[mSlot.Index]. Reported) ^ mSlot = vSlots[mSlot.Index] 
sync CepReply!(mStatus,mSlot) 
vSlots[mSlot.Index].Reported := true 
vSlotsReported := vSlotsReported + 1 



(not mType = FirstSlot) ^ (not mType = NextSlot) 
sync CepInquiry?(mType) 




vSlotsReported = pSlotCount ^ mStatus = Finished 
sync CepReply!(mStatus,mSlot) 



J mType = NextSlot 
sync CepInquiry?(mType) 



mStatus = SequenceError 
sync CepReply! (mStatus, mSlot) 



Fig. 2. Specification 



The terminal to card interface for CEPS is based on command/response 
pairs, so the interaction between terminal and card begins with a Cepln- 
quiry command with a parameter mType equal to FirstSlot (i.e., the 
transition from LO to LI). After receiving this command the application 
performs internal computations to initialize the array of slot informa- 
tion (vSlots), marking slots that are in use as ready for reporting (i.e., 
vSlots [...]. Reported := false). This array has parametric size specified 
as pSlotCount. The initialization is in essence a “for” loop on variable 
vSlotIndex from zero to pSlotCount minus one at location LI. 

When vSlotIndex reaches pSlotCount, an internal action is executed, 
taking the application to location L2 where it is ready to send its first 
reply and, if applicable, accept commands requesting subsequent slots. If 
the card has zero slots to report (i.e., there are no currencies stored in 
the card), a reply with status “Finished” is sent (transition from location 
L2 to location L3) and the feature has completed its processing. If the 
card has one or more currencies to report, the transition from location L2 
to location L4 is taken, returning the balance of one slot to the requester 
and marking that slot as having been reported. 

At location L4 the application waits for the next balance request com- 
mand, returning to location L2 when it is received. Receiving a “First- 
Slot” command at this point will re-initialize the iteration (transition L4 
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mType = FirstSlot 
sync CepInquiry?(mType) 

mStatus = Finished 
sync CepReply!(mStatus,mSlot) 

) 

O Accept 



mStatus = Normal 
SyncCepReply!(mStatus,mSlot) 




Fig. 3. Test Purpose 



to LI). If a command other than “FirstSlot” or “NextSlot” is received a 
sequence error is generated (transition L4 to L5 to L6). 

The test purpose. A test purpose is used to select the behaviors from 
the specification that are to be exercised by the derived test. Figure 3 
illustrates a test purpose that selects from the CEPS slot inquiry feature 
a test that exercises a single iteration through all the slots of the card, 
uninterrupted by sequence errors or re-starting of the iteration. 

The test purpose is also an lOSTS, with locations and transitions. 
The generation of tests takes place through the computation of a product 
between the specification lOSTS and the test purpose lOSTS. Thus, loca- 
tions in the test are pairs made up of a location from the specification and 
a location from the test purpose, and transitions between these locations 
are added when (1) a specification transition action has the same label 
as a test purpose action (resulting in a guard that is the intersection of 
the specification and test purpose transition guards), or (2) the specifica- 
tion is capable of advancing on an internal action (with the guard taken 
directly from the specification edge). The location “Accept” in the test 
purpose indicates locations in the test lOSTS that should be interpreted 
as final, indicating successful execution of the test. 

The test purpose of Figure 3 was constructed to select behaviors that 
(1) begin with a “FirstSlot” command, (2) loop as many times as neces- 
sary to process all slots, and (3) accept behaviors that conclude with 
a “Finished” reply. When there are no slots loaded with currency in 
the purse “Finished” may correctly be generated without any “Normal” 
replies being generated. 



The test. Finally, Figure 4 shows the lOSTS that results from symbolic 
test generation using the specification of Figure 2 and test purpose of 
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Figure 3. Note that this test is specific to this test purpose. Different test 
purposes will generate different tests. 

The computation steps carried out are identical to those given in the 
specification. Actions have had their orientation (ie.^ input vs. output) 
reversed so that the test becomes a generator of commands and a receiver 
of responses, complementary to an implementation of the specifications. 

The location labelled “Pass” in Figure 4 indicates that a correct inter- 
action between the tester and the system under test took place. The sym- 
bolic test generation method also generates transitions from every loca- 
tion to a new location “Fail” that absorb incorrect responses from the sys- 
tem under test and lead to the “Fail” state, indicating non-conformance 
of the implementation. For the sake of clarity of presentation, only one 
of these transitions is shown in detail in the figure. In fact each possible 
erroneous input action the tester could receive generates a transition to 
“Fail” from each location of the graph. 

Note that the test shown in Figure 4, like all tests generated by this 
method, incorporates its own oracle. All of the computation steps neces- 
sary to verify the correctness of numeric results are extracted from the 
specification and used by the tester to verify arguments as they are re- 
ceived. This is in contrast to test generation techniques that simply pro- 
duce a sequence of inputs to drive the implementation through a specific 
path. 

4 Test Automation 

A goal of our work is to produce a fully automated process for sym- 
bolic test generation and execution, from high-level specifications down to 
executable test programs. Our present work is focused on test generation 
from 10 STS (a formal model intended as an intermediate representation) 
down to C++ test objects. In this section we present a summary of tool 
support for test generation, and outline the test execution phase 

Tool Support. The test derivation technique described in Section 3 is 
implemented in a tool called “Symbolic Test Generator,” or simply STG. 
This tool currently implements the functions outlined by a dashed box 
in Figure 1. This includes (1) reading and parsing lOSTS specifications 
expressed in a dialect of IF [BFG"^99], (2) computing an lOSTS test case 
from an lOSTS specification and lOSTS test purpose according to the 
theory of [RdBJOO], and (3) translation of the lOSTS test case to C++, 
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o 

mType = FirstSlot 
sync Cepinquiry! (mType) 
vSlotIndex := 0 
vSlotsReported := 0 



vSlotIndex < pSlotCount ^ not vSlots[vSlotIndex].InUse 

sync tan 

vSlots[vSlotIndex], Reported := true 
vSlotIndex := vSlotIndex + I 
vSlotsReported := vSlotsReported + 1 

vSlotIndex = pSlotCount ^ 
mStatus = Normal ^ vSlotsReported < pSlotCount ^ 
mSlot.Index >= 0 ^ mSlot.Index < pSlotCount ^ 
(not vSlots [mSlot.Index] .Reported) ^ mSlot = vSlots [mSlot.Index] 
sync CepReply?(mStatus,mSlot) 
vSlots[mSlot.Index]. Reported := true 
vSlotsReported := vSlotsReported + 1 ^ 
O 

mStatus = Normal ^ vSlotsReported < pSlotCount ^ 
mSlot.Index >= 0 ^ mSlot.Index < pSlotCount ^ 
(not vSlots [mSlot.Index] .Reported) ^ mSlot = vSlots [mSlot.Index] 
sync CepReply?(mStatus, mSlot) 
vSlots[mSlot.Index]. Reported := true 
vSlotsReported := vSlotsReported + 1 

O 





not (vSlotIndex = pSlotCount ^ 
vSlotsReported = pSlotCount ^ mStatus = Finished) 
and not (mStatus = Normal ^ vSlotsReported < pSlotCount ^ 
mSlot.Index >= 0 ^ mSlot.Index < pSlotCount ^ 
(not vSlots [mSlot.Index] .Reported) ^ mSlot = vSlots [mSlot.Index]) 
sync CepReply?(mStatus, mSlot) 

Fail 



vSlotIndex = pSlotCount ^ 

vSlotsReported = pSlotCount ^ mStatus = Finished 
sync CepReply?(mStatus, mSlot) 



V ... 



Fig. 4 Test 
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ready to be compiled, linked to an interface-compatible implementation, 
and executed. 

The inputs of the tool, (1) the lOSTS specification and (2) the lOSTS 
test purpose (s), are constructed manually by the system engineer using 
a text editor. Ultimately our goal is to create these inputs automatically 
based on a pre-existing formal high-level specification model, and higher 
level descriptions of test objectives such as coverage criteria. 

For translation of test cases to executable code the guard expressions 
of system inputs are limited to formulas in Presburger arithmetic. This 
is because we depend on the Omega [KMP"^] library (for analyzing Pres- 
burger formulas) to evaluate the constraints and select specific values for 
outputs of the tester. In practice this means that expressions on guards of 
system inputs in the lOSTS specification cannot contain any operations 
more complex than arithmetic {Le., addition, subtraction, relational op- 
erators, boolean operators) or multiplication by constant factors. 



Test Execution The C++ tests are generated based on various assump- 
tions about how the lOSTS model maps into the C++ programming 
language. For example, inputs and outputs of the lOSTS become func- 
tion calls and return values, respectively, in the generated C++ code. The 
system under test is assumed to be a C++ class, and inputs to the sys- 
tem under test are implemented as synchronous method invocations with 
messages passed through function arguments. The reply of the system 
under test is the received return value of the method invocation. 

Implementations that present an interface corresponding exactly to 
this model can be compiled with the resulting test program to produce 
an executable test. Other systems will require the creation of a simple 
intermediate module that implements the interface described and trans- 
lates communication into the model expected by the system under test. 
For example, in the smart card domain, testing of an application resident 
on a card would require the creation of an interface module to translate 
method invocations and their parameters into a command APDU, send 
the APDU to the card over the terminal-to-card interface, wait for the 
reply APDU, interpret the reply APDU and return the reply value(s) to 
the method’s caller. 

Once a test and interface-compatible system are compiled together 
into executable code, the actual execution of the test consists of (1) sup- 
plying any parameter values that are required by the model, and (2) 
observing the final verdict of the test: “pass,” “inconclusive” or “fail.” 
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5 Summary 

This paper has presented a symbolic test generation technique which has 
been successfully applied to test generation for smart card applications. 
The symbolic generation technique (1) automatically derives test cas- 
es in order to check conformance of an implementation with respect to 
the behavior of a specification selected by the test purposes; (2) auto- 
matically determines whether the results of the test execution are correct 
with respect to the specification. It performs test derivation as a sym- 
bolic process, up to and including the generation of test program source 
code. The reason to use symbolic techniques instead of enumerative is 
that symbolic test generation allows us to produce (1) more general test 
cases with parameters and variables which should be instantiated only 
before the test cases execution, and (2) test cases that are more readable 
by humans. We presented an example based on the application of these 
techniques to a feature of the CEPS e-purse specifications. 

We are currently using the lOSTS language and STG to develop a 
large-scale case study based on the CEPS specifications. The lOSTS 
graphs presented in Section 3 are a small part of the current model, 
which will ultimately include all of the command processing functions 
of the CEPS specifications. During the development of this model, STG 
is being used to incrementally test a prototype implementation of the 
specifications. 

Other directions for our future work include, firstly, the use a higher- 
level language {e.g.^ LOTOS, SDL, etc.) for specifying systems at the user 
level. Second, we plan to work on the implementation of a mechanism to 
automatically compute test purposes from the system specification using, 
for example, coverage criteria instead of test purposes written by hand. 
Third, we continue to work on simplification of test cases, as we want 
to reduce the size of test cases, which would result in reduced execution 
time, improved readability, elimination of paths leading to “Inconclusive” 
verdicts, etc. There are two directions to solve the problem: (1) the test 
cases could be simplified using automated static analysis and proof strat- 
egies; or (2) the test cases could be derived from an abstraction of the 
system specification instead of the concrete specification. 
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Abstract. This paper presents an authorization scheme for applications 
distributed on the Internet with two levels of access control: a global 
level, implemented through a fault- and intrusion-tolerant authorization 
server, and a local level implemented as a security kernel located on 
both the local host Java Virtual Machine (JVM) and on a Java Card 
connected to this host. 

1 Introduction 

Today, most Internet applications are based on the client-server model. In this model, 
typically, the server distrusts clients, and grants each client access rights according to 
the client’s identity. This enables the server to record a lot of personal information 
about clients: identity, usual IP address, postal address, credit card number, purchase 
habits, etc. Such a model is thus necessarily privacy intrusive. 

Moreover, the client-server model is not rich enough to cope with complex 
transactions involving more than two participants. For example, an electronic 
commerce transaction requires usually the cooperation of a customer, a merchant, a 
credit card company, a bank, a delivery company, etc. Each of these participants has 
different interests, and thus distrusts the other participants. 

Within the MAFTIA[]project, we are developing authorization schemes that can grant 
to each participant fair rights, while distributing to each one only the information 
strictly needed to execute its own task, i.e., a proof that the task has to be executed 
and the parameters needed for this execution, without unnecessary information such 
as participant identities. These schemes are based on two levels of protection: 

• An authorization server is in charge of granting or denying rights for high-level 
operations involving several participants; if a high-level operation is authorized, 
the authorization server distributes capabilities for all the elementary operations 
that are needed to carry it out. 



^ MAFTIA (Malicious- and Accidental-Fault Tolerance for Internet Applications) is a 
European project of the 1ST Program. MAFTIA partners are University of Newcastle upon 
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(F), University of Lisbon (P) and University of Saarland (D). See http://www.maftia.org/. 
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• On each participating host, a security kernel is responsible for fine-grain 
authorization, i.e., for controlling the access to all local resources and objects 
according to the capabilities that accompany each request. To enforce hack- 
proofing of such security kernels on off-the-shelf computers connected to the 
Internet, critical parts of the security kernel will be implemented on a Java Card. 

In the following sections, the general authorization architecture and the security 
kernel are described, and an illustrative example is presented. Finally, our approach is 
compared to related work. 



2 General Authorization Architecture 

In [Nicomette & Deswarte 1997], we proposed a generic authorization scheme for 
distributed object systems. In this scheme, an application can be viewed at two levels 
of abstraction: high-level operations and method executions. A high-level operation 
corresponds to the coordinated execution of several object methods towards a 
common goal. For instance, printing file F3 on printer P4 is a high-level operation 
involving the execution of a printfile method of the spooler object attached to P4, 
which itself has to request the execution of the readfile method of the file server 
object managing F3, etc. 

A request to run a high-level operation is authorized or denied by an authorization 
server, according to symbolic rights stored in an access control matrix managed by the 
authorization server. More details on how the authorization server checks if a high- 
level operation is to be granted or denied are given in [Nicomette & Deswarte 1996] 
and [Abghour et al 2001]. If the request is authorized, capabilities are created by the 
authorization server for all the method executions needed to realize the high-level 
operation. These capabilities are simple method capabilities if they are used directly 
by the object requesting the execution of the high-level operation, i.e., used by this 
object to directly call another object’s methods. Alternatively, the capabilities may be 
indirect capabilities or vouchers, if they cannot be used by the calling object but must 
be delegated to another object that, itself, will invoke other object methods to 
participate in the high-level operation. In fact, the notion of high-level operation is 
recursive, and a voucher can contain either a method capability or the right to execute 
a high-level operation. 

This delegation scheme is more flexible than the usual ''proxy scheme, by which an 
object transmits to another object some of its access rights for this delegated object to 
execute operations on behalf of the delegating object. Our scheme is also closer to the 
"least privilege principle’’', since it helps to reduce the privileges needed for 
performing delegated operations. For instance, if an object O is authorized to print a 
file, it has to delegate a read-right to the spooler object, for the spooler to read the file 
to be printed. To delegate this read-right, with the proxy scheme, O must possess this 
read-right; so O could misuse this right by making copies of the file and distributing 
them. In this case, the read-right is a privilege much higher than a simple print-right. 

In our scheme, if O is authorized to print a file, O will receive a voucher for the 
spooler to read the file, and a capability to call the spooler. The voucher, by itself, 
cannot be used by O. With the capability, O can invoke the spooler and transmit the 
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voucher to the spooler. The spooler can then use the voucher as a capability to read 
the file. 

Since only high-level operations are managed by the authorization server, it is 
relatively easy to manage: the users and the security administrators have just to assign 
the rights to execute high-level operations, they do not have to consider all the 
elementary rights to invoke object methods. Moreover, since only one request has to 
be checked for each high-level operation, the communication overhead can be 
reduced. 

The authorization server is a trusted-third-party (TTP), which could be a single-point- 
of-failure, both in case of accidental failure, or in case of successful intrusion 
(including by a malicious administrator). To prevent this, with the MAFTIA 
authorization architecture [Abghour et al 2001], the authorization server will be made 
fault- and intrusion-tolerant: an authorization server is made of diverse security sites, 
operated by independent persons, so that any single fault or intrusion can be tolerated 
without degrading the service. The global architecture is given by Figure 1. 




The dialogue between a MAFTIA object and the authorization server may typically 
be the following one: 

Object O asks the authorization server for the authorization to carry out an operation 
in the system. This operation may be the simple invocation of a particular method of a 
particular object or may be a “high-level operation” that requires the collaboration 
between several objects in the system. 

In the first case, if object O is authorized to carry out the operation, it receives a 
capability. This capability will be presented and checked by the security kernel 
located on the site of the invoked object. 
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In the second case, the user may receive capabilities and vouchers. Capabilities are 
directly used by object O to invoke particular methods of particular objects. 
Vouchers are not used by object O but are delivered to object O for objects that are 
involved in the realization of the high-level operation (e.g., a capability for 0’ to 
invoke a method m of object O”, as a part of the high-level operation). These 
vouchers will thus be transferred by object O to other objects, which will then 
realize their part of the high-level operation thanks to these vouchers. A voucher 
may be a capability or the right to realize another high-level operation. 

The following figure summarizes this protocol: 




a) Simplemethod invocation 

1. O requests authorization to invoke method m of’ 

Cap(0, O’.m) 

3. O receives a capability for m of ’ 



Authorization 

Server 



2. The authorization server 
checksif the invocation 
is authorized 



b) High-ievei operationinvocation 



©. 



Authorization 

Server 



1. O requests authorization to carry out a high- 
operation 

^ Cap(0, O’.m), vouch(hlo)(0’)... 

3. O receives capabilities and vouchers necessary for 

the high-level operation realization 2. The authorization server 

checksif the higNevel 
operation is authorized 



Fig. 2. Protocol between a MAFTIA object and the authorization server 



3 Security Kernel 

There is a security kernel on each host participating in a MAFTIA-compliant 
application. The security kernel is responsible for granting or denying local object 
method invocations, according to capabilities and vouchers distributed by the 
authorization server. In the context of wide-area networks (such as the Internet), the 
implementation of such a security kernel is complicated since, due to the 
heterogeneity of connected hosts, it would be necessary to develop one version of the 
security kernel for each kind of host. Moreover, since the hosts are not under the 
control of a global authority, there is no way to ensure that each host is running a 
genuine security kernel, or the same version thereof. This is why we have chosen to 
implement them by using Java Cards. 

3.1 Implementation 

A security kernel in the context of a MAFTIA site is composed of a local Java Virtual 
Machine (JVM), a Java Card and a Dispatcher. The Dispatcher is a local object that 
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always runs on each MAFTIA site and that is in charge of dispatching remote 
requests to the local objects (a more precise description is given in the next section). 
There is no specific requirement for the local JVM, it may be the JVM of a browser 
such as Netscape or Internet Explorer for instance. This JVM must simply be 
compliant with JDK1.2 and thus able to check a signature (for a signed class). 

The Java Card has the responsibility of deciding whether or not to authorize the 
invocation of particular methods on particular objects on the local host by checking 
that the corresponding capabilities are presented. These checks represent the central 
part of the authorization scheme, and thus have to be protected as strongly as possible. 
We have chosen to implement them on a Java Card, which we consider as sufficiently 
tamperproof In particular, any software, even that within an operating system or a 
JVM, can be copied and modified by a malicious user who possesses all privileges on 
a local host. In particular, on Internet, any hacker can easily have these privileges on 
his own computer! With capability checks run on the Java Card, we can be sure that 
any remote request to execute a MAFTIA-application is genuine (if the capability is 
correct), and that a genuine MAFTIA request can only be executed on the host for 
which the capability is valid. The hacker’s privileges on his host gives him no 
privilege outside that host. 

The capability checks carried out by the Java Card are based on strong 
cryptographic functions. Several cryptographic keys must be included in the Java 
Card: 

• The MAFTIA public key, that we note PKm (this key is associated to the 
MAFTIA private key SKm, which is not stored in the Java Card); 

• A private/public key pair specific to the Java Card, that we note SKj, PKj; 

• The authorization server public key, PKas (this key is associated to the private 
key of the authorization server, SK^s)- 

The role of these cryptographic keys is explained in Section 3.3. 

3.2 Programming Paradigm 

Each MAFTIA application is implemented by means of a set of Java classes. Each 
MAFTIA object is thus a Java object loaded by a local JVM. The interaction between 
objects is realized through Java RMIs (Remote Method Invocations). All parameters 
(including capabilities, vouchers and returned values) are thus exchanged between 
objects by passing messages corresponding to these Java RMIs. 

Each dispatcher is known by the authorization server and all requests to objects on a 
site must be intercepted by the local dispatcher. Then, each capability or voucher 
created by the authorization server and returned to an object requesting to carry out an 
operation in the system, is accompanied by the reference of the corresponding 
dispatcher. The object that receives this capability or voucher must invoke the 
dispatcher and present it the capability it has received from the authorization server. 
The capabilities are checked using the cryptographic functions included in the Java 
card, as explained in the next section. 
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3.3 Protocol 

A distributed MAFTIA application is executed by means of method invocations 
between MAFTIA objects located on MAFTIA-compliant hosts. The objects are 

signed off-line by the global MAFTIA private key and this signature is checked 
by the local JVM of the host (since version 1 .2, the Java Development Kit includes 
software that allows classes to be signed and the signatures to be checked at load 
time). 

As explained in the previous section, invocations are conveyed between objects by 
message passing. When an object is authorized to invoke a particular method of a 
particular object, it invokes the dispatcher of the corresponding site and gives it the 
capabilities received from the authorization server that authorize this access (see Step 
1 of Figure 3). 



1 . A message carrying capabilities and vouchers 




Fig. 3. Example of a voucher corresponding to a capability 



Capabilities are ciphered by the public key PKj of the local Java Card and signed by 
the private key of the authorization server. The capability signature must first be 
verified using the authorization server’s public key, and then deciphered by the 
cryptographic functions of the Java Card using the private key SKj, which is stored 
only in the Java Card. Each access to a method of an object on a MAFTIA site is thus 
controlled by its local Java Card. This verification corresponds to step 2 of Figure 3. 
The invocation message may contain vouchers. As explained before, a voucher may 
be a capability or the authorization to carry out a high-level operation in the system. A 
voucher is not used by the object requesting the operation but is delegated to another 
object involved in the realization of the current operation. 

If the voucher is a capability, this capability is thus ciphered by the public key of the 
corresponding Java Card and thus, will be checked by the corresponding security 
kernel. Step 3 of Figure 3 presents an example of such a voucher. 

If the voucher is the authorization to realize a high-level operation, it is transmitted to 
another object, which uses this voucher in the following way: the voucher is presented 
to the authorization server as a proof that the object is authorized to realize a 
particular operation (step 3 of Figure 4). The authorization server simply checks the 
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validity of this voucher and then delivers to the object the corresponding capability 
and vouchers. 



1 . A message carrying capabilities and vouchers 
is received by the local dispatcher (D). 

2. A method of O is invoked once the capability authorizing this access 
has been verified by the Java card crypto functions. 

3. The message holds a voucher that is the right for O to carry out 




Fig. 4. Example of a voucher corresponding to a high-level operation right 



4 A Healthcare Example 

In the following example, we consider that a doctor wants to transfer a copy of a 
patient medical file to another healthcare professional. The set of objects that take part 
in the execution of this high-level operation are presented in Figure 5. In this figure, U 
is a doctor, V is another healthcare professional (with role HCP^ DBS (of class 
DATABASESERVER) is a database server, (of class PATIENTMEDICALFILE) is 
the medical file of a patient of Doctor U. MTAl and MTA2 are mail transport agents, 
which are given the responsibility to transmit electronic mail. The class of these 
objects is MTA. Finally, tf is Si transient file located on the site of DBS. 

Using delegation of rights through vouchers, a sufficient access control matrix is 
given in the following table: 



Table 1. Access control matrix 







HCPRole 


{Prnfm 


u 




TPmf{{Pmf(U)}, this) 


read, write, 

TPmf {this, HCP Role) 


DBS 

















2 



We also use the notations U and V to designate the objects representing these persons in the 
information system. 
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The scenario that enables U to transfer a copy of a patient medical file to another 
healthcare professional is described here. We indicate in this scenario the functions of 
the authorization server and the security kernels with respect to capability distribution 
and verification. 




Fig. 5. Example of a high-level operation 

User U wants to transfer a patient medical file to a user V. The user U asks the 
authorization server for the authorization to execute the high-level operation 
transferPatientMedicalfile (Pmf, V). The authorization server checks that in the access 
matrix, IPs row holds sufficient symbolic rights to grant the authorization of this 
operation (see footnote 2). In this case, U has the symbolic right TPmf for any user 
with the role HCP (Healthcare Professional), and for the Pmf of all t/’s patients[] 
Since U is a healthcare professional, TPmf (Pmf Role (V)) and TPmf 
(PatientMedicalFile, V) are both authorized and the high-level operation authorization 
has to be granted. 

Consequently, the authorization server transfers the following privileges to user tU 
{ Cap (U, DBS. transferPatientMedicalfile (Pmf V)), 

[Cap (DBS, PmfreadPatientMedicalfde ()f\, 

[Cap (DBS, MTAl.sendPatientMedicalfile (char * Vf\, 

[7? (deliverPatientMedicalfile)(MTAl, char * FJ] } 



^ {Pmf(U)} represents the set of the medieal files of all patients of Doetor U. In this aeeess 
eontrol matrix, U also possesses the rights to invoke methods read and write of any ohjeet in 
the set {Pmf(U)}. 

^ Cap(0, 0\m()) denotes the eapahility for ohjeet O to invoke method m of ohjeet 0\ 
[Cap(0\ 0”.m())] represents a voueher eontaining the eapahility for O' to invoke method m 
of ohjeet O”. [R(hlo)(0\ <parameters>)] represents a voueher eontaining the right for O' 
to realize the high-level operation hlo. This voueher notation [X\ is equivalent to the 
notation voueh(Y) in Figure 2. 
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• Cap (U, DBS.transferPatientMQdic 2 i\fi\Q (Pmf, V)) is the capability for U to 
invoke DBS’s method transfer? atientMedicalfile with parameters corresponding 
to the specific patient medical file Pmf and to the heathcare professional V. 

• The voucher [Cap (DBS, Pmf read? atientMedicalfile ())] represents the 
capability for the database server DBS to read the patient medical file. 

• The voucher [Cap (DBS, MTAl.sendPatientMedicalfile (char *, V)] represents 
the capability for the database server DBS to send a patient medical file to V. 

• The voucher [R (deliverPatientMedicalfile)(MTAl, char *, V)] represents the 
right for the mail transport agent MTAl to perform a high-level operation 
deliverPatientMedicalfile (char * V). This voucher is accompanied by the 
capability to invoke transferpatientmedicalfile and returned to the object 
authorized to carry out the action transferPatientMedicalfile (Pmf, V). This object 
will transfer the voucher to DBS, which will transmit it to MTAl when it wants to 
carry out a high-level operation deliverPatientMedicalfile (char * V). 

U invokes method transferPatientMedicalfde of DBS. This invocation carries the 
capability Cap (O, DBS. transferPatientMedicalfde (Pmf V)) and the 3 vouchers 
(message 1). The invocation authorization is checked by the security kernel located on 
the site of DBS, which verifies that the capability is valid. 

DBS then invokes method readPatientMedicalfde to read the patient medical file Pmf 
and presents the voucher received previously from U (message 2). The security kernel 
located on Pmf^ site checks the validity of the capability 
Cap (DBS, Pmf.readPatientMedicalfde ()). 

DBS receives data from the patient medical file and creates a temporary file tf to be 
used hy MTAl. When creating tf, DBS receives the owner capability on this file from 
its local security kernel. Then DBS copies Pmf mto tf hy the way of message 3 (the 
write access to tf\^ authorized because DBS presents the owner capability to the 
security kernel). 

DBS asks the security kernel to create capabilities fox MTAl to access tf methods read 
and delete (by presenting the owner capability to the security kernel). Using the 
voucher [Cap (DBS, MTAl.sendPatientMedicalfile) (char * V))'\ received from U, 
DBS invokes method sendPatientMedicalfile of MTAl and transfers tf read and delete 
capabilities and the voucher [R (deliverPatientMedicalfile) (MTAl, char * V)'\ to 
MTAl for it to perform the high-level operation deliverPatientMedicalfile (tf, V) 
(message 4). The security kernel located on the site oiMTAl controls the invocation 
by checking the capability Cap (DBS, MTAl. sendPatientMedicalfile) (char * V)). 
MTAl asks the authorization server for the authorization to execute the high-level 
operation deliverPatientMedicalefile (tf, V) and presents the voucher received from 
DBS. 

The authorization server checks that the voucher presented by MTAl is valid (i.e., is a 
right for MTAl created by the authorization server). Then the authorization server 
identifies MTA2 as the mail transport agent for V, and finally gives MTAl the 
privileges corresponding to the action deliverPatientMedicalfile (tf, V), which are 
{ Cap (MTAl, MTA2.receive (char * V.)), [R (deliver) (MTA2, char * V))] }. 

[R (deliver) (MTA2, char * V))^ is a voucher that has to be delegated to MTA2 to 
perform the high-level operation deliver. 
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MTAl calls method read of tf (message 5). This invocation is controlled by tf^ local 
security kernel, which checks that MTAl holds the capability for method read of tf. 
ThenMZ47 invokes method receive(<content of tf>, V) of MTA2 (message 6). Once 
this method has been invoked, MTAl sends a request to delete tf The security kernel 
located on the site of MTA2 checks the validity of the capability 
Cap (MTAl, MTA2. receive (char * V.)). 

MTA2 asks the authorization server for the authorization to execute the operation 
deliver on Fs mailbox and presents the voucher [R (deliver) (MTA2, char * VJJ] 
received from MTAl . 

The authorization server first checks that the voucher is valid, and gives MTA2 the 
capability Cap (MTA2, VMailbox.mdeliver(char enabling it to invoke the method 
mdeliver of the object Vmailbox corresponding to F’s mailbox (message 7). 

5 Related Work 

The basic authorization scheme was developed in [Nicomette 1996]. This work was 
the first attempt to introduce the voucher delegation scheme, and to demonstrate its 
ability to implement closely the least privilege principle. 

Other schemes have been recently introduced to provide more flexibility and more 
efficiency than the client-server model. In particular, [Ao et al 2001] proposes to 
carry out access control in a distributed system by means of “communal laws”. This 
paper addresses also the problem of revocation, which is not directly addressed in our 
scheme, even if an expiry time can be included in our capability and vouchers. 
However it seems that the scheme presented in [Ao et al 2001] may be difficult to 
implement. 

The notion of “authorization server” is now relatively common when consistent 
access control has to be implemented in distributed systems. Even some public key 
infrastructure (PKI) implementations, such as SPKI [Ellison 1999], can be seen as a 
kind of authorization service. In the same way, Kerberos V5 Ticket Granting Server 
[Neuman & Tso 1994] and SESAME Privilege Attribute Services [Parker 1991], 
manage some authorization, but only at a coarse-grain level, for client-server 
interactions. Delta-4 [Blain & Deswarte 1990] proposed also an authorization service, 
which has been implemented to control access to a persistent file storage service. 
Delta-4 was also the first attempt to implement fault- and intrusion-tolerant security 
services. Other recent authorization server implementations are the HP Praesidium 
[HP 1998] and Adage [Zurko et al 1999]. 

Concerning the use of smart cards for authorization, let us cite [Au et al 2000] which 
proposes to use smart cards as portable, tamperproof storage for authorization tokens 
delivered by an authorization server and checked by an “authorization manager” (the 
equivalent of our security kernel) on each application server. In their approach, the 
smart card is not used to implement the authorization manager of the application 
server, it is just used to store the authorization token. JCCap [Hagimont & 

Vandewalle 2000] proposed the use of capabilities to manage access controls between 
applications located on Java Cards, but their capabilities are defined statically by 
means of “views” during program development, rather than created dynamically by 
an authorization server. We consider that our approach is more flexible and closer to 
the least privilege principle. 
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6 Conclusion 

The authorization scheme presented in this paper is flexible, easily managed (at the 
coarse-grain level of “high-level operations”), and efficient (fine grain access control 
at the object method invocation level, tamperproof security kernels implemented with 
Java Cards). Moreover, it is not privacy intrusive, since personal information is 
disclosed to participants only on a “need-to-know” basis. 

Since the implementation has just begun, no performance measurements are currently 
available. But since the authorization server is accessed only once for each high-level 
operation, we hope that the induced overhead will be acceptable with respect to the 
gained security and privacy. 
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Abstract. This paper presents a way to improve smart card integra- 
tion in distributed information systems. Multi-application smart cards 
are able to offer a lot of services, but at the same time they are mainly 
disconnected. Our main goals are to ease the use of such services and 
to increase their availability. In order to reach them, we propose a JMS- 
SOAP based platform that enables remote clients both to discover what 
services a smart card provides and to request any service either syn- 
chronously and asynchronously. 



1 Introduction 

Four years ago, Java Cards induced a revolution in smart cards world. With 
Java Cards, smart card application design is no more a specialist job. Although 
smart card application Time- to- Market was before about 6 months long, every 
programmer familiar with the Java language and technology is now able to write 
and ship his first smart card application in few days. Consequently, open smart 
cards boosted smart card use. 

Even if Java Cards are mostly involved in simple client- servers applications, 
one of the most promising role for open smart cards in distributed informations 
systems is to act as mobile agents or application servers. Emerging technologies 
consider World Wide Web as a universal medium for interoperable services de- 
ployment, discovery and use. We think that open smart cards, and particularly 
Java Cards, can smartly take a place in such a model. Nevertheless, smart cards 
are disconnected most of their lifetime, even if SIM^ cards (in mobile phones) 
are exceptions. This feature of smart cards has to be taken into account. In this 
paper, we present how multi- applications smart cards, and distributed applica- 
tions in which they are involved, can take benefits of middlewares that provide 
interoperability and asynchronous messaging. 

^ Subscriber Identification Module 
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Next Section briefly presents SOAP and related technologies as well as Mes- 
sage Oriented Middlewares (MOM). After this overview, Section 3 takes a look 
at five years of Java Cards application model evolution. Then, Section 4 explains 
why and how to involve Java Cards in heterogeneous information systems where 
exchanges are synchronous or not, and gives implementation issues. Finally, Sec- 
tion 5 concludes and presents future work. 

2 MOMs and Services over the Web 

In this Section, we discuss technologies and concepts involved in our proposal. We 
briefly overview MOM technology and present emerging standards for deploying 
and using services aver the Web. 



2.1 Message Oriented Middlewares 

Message Oriented Middlewares (MOM) [1] are based on asynchronous messages 
as the single structure for communication, coordination and synchronization, 
thus allowing desynchronized execution of components. Reliable communication 
is guaranteed by message queuing techniques or specific communication protocols 
that can be added independently from the programming of software components. 
Asynchronous communication property decouples producers of information from 
consumers. They do not need to be both ready for execution at the same time. 
mom’s goal is also to maximize the portability of the transmission of messages 
between several applications. 

JMS [2] is a specification of a MOM based on Java Technology. It defines a set 
of interfaces for messages queuing. JMS provides the application designers with 
two messaging models, as presented on Figure 1. The first is Point-To-Point^ 
where a producer and one ore more consumers are highly coupled^. The other is 
Publish- Subscribe^ where a producer delivers messages related to an existing topic 
and where consumers have just to subscribe in order to receive next messages of 
the subscribed topic. JMS is just a standard de facto ^ it is not a product by itself. 
However, there are a lot of commercial implementations compliant with this 
specification and a lot of open-source projects (as the example of JORAM[3]). 

2.2 SOAP, UDDI and WDSL: Deploying Services over WWW 

The World Wide Web was originally created to enable information exchange in 
a simple and portable way across the Internet. It resides in a combination of 
four elements: 

1. HyperText Transport Protocol (HTTP), a client-server protocol on top of 
TCP-IP. 

2. Uniform Resource Locator (URL), a universal binding system. 

^ However JMS, as a MOM, guarantees that a message is delivered only once even if 
several consumers are connected to the producer’s queue 
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Fig. 1. Messaging models in JMS 



3. HyperText Markup Language (HTML). 

4. Web browsers. 

From sharing information between scientists, WWW moved to mass mar- 
ket. Server-side Scripting technologies, like CGI (Common Gateway Interface), 
turned the Web as a universal medium for client-server applications. These tech- 
nologies have however some drawbacks, like the hardness to manage sessions and 
the lack of interoperability. So, Client-server programming over the web had to 
evolve to reach the goal of interoperability, simplicity and portability: the answer 
was SOAP. 

SOAP [4] is a lightweight protocol for exchange of information in a decen- 
tralized, distributed environment. It is an XML based protocol that consists of 
three parts: 

1. An envelope that defines a framework for describing what is in a message 
and how to process it. 

2. A set of encoding rules for expressing instances of application- defined data 
types. 

3. Conventions for representing remote procedure calls, responses and errors. 

SOAP can potentially be used in combination with a variety of other protocols. 
However, the bindings defined for the moment describe how to use SOAP in 
combination with HTTP, and how to wrap RPC on SMTP and HTTP. An 
example of SOAP messages (transported with HTTP) is presented below, in the 
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context of a quotation service. The request is transported in an HTTP’s POST 
request (Figure 2) and the answer conies back in an HTTP response (Figure 3). 



POST /StockQuote HTTP/1.1 
Host: www.stockquoteserver.com 
Content-Type: text/xml; charset="utf-8" 

Content-Length: 478 
SOAPAction: "/StockQuote" 

<SOAP-ENV : Envelope 

xmlns : SOAP-ENV="http : //schemas . xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www. w3 . org/1999/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/1999/XMLSchema" > 

<SOAP-ENV:Body> 

<m : GetLastTradePrice xmlns : m="http : //www . stockquoteserver . com/ns " 

SOAP-ENV : encodingStyle="http : //schemas . xmlsoap . org/soap/encoding/"> 
<symbol xsi : type="xsd: string">DIS</symbol> 

</m : GetLastTradePrice> 

</SOAP-ENV:Body> 

</SOAP-ENV : Envelope> 



Fig. 2. Quotation service request 



HTTP/ 1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 

Content-Length: 490 

<S0AP-ENV : Envelope 

xmlns : SOAP-ENV="http : //schemas . xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www . w3 . org/1999/XMLSchema-instance" 
xmlns : xsd="http : //www . w3 . org/1999/XMLSchema" > 

<SOAP-ENV:Body> 

<m : GetLastTradePriceResponse xmlns : m="http : //www . stockquoteserver . com/ns " 

SOAP-ENV : encodingStyle="http : //schemas . xmlsoap . org/soap/encoding/"> 
<Price xsi :type="xsd: float " >34. 5</Price> 

</m : GetLastTradePriceResponse> 

</SOAP-ENV:Body> 

</S0AP-ENV : Envelope> 



Fig. 3. Quotation service response 



A service request using SOAP/HTTP is completed according to the follow- 
ings steps: 

1. the client builds the SOAP message, according to the service description 

2. The SOAP message is encapsulated in an HTTP POST request and trans- 
ported to the Web server hosting the service 

3. The Web server forwards the SOAP message to an RPC router server-side 
script or servlet 
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4. The RPC router: 

(a) parses the SOAP message, 

(b) realizes the invocation, 

(c) gets the response, 

(d) sends back and HTTP response containing the SOAP response (normal 
or error) 

5. The SOAP response is sent back to the client 

6. The client parses the SOAP response and processes it 

SOAP is an easy and extensible way to request services across the Web. It 
is independent from operating systems, programming languages and transport 
protocols. SOAP is not an object-oriented distributed system, there is no garbage 
collection neither object activation (parameters are not object references but 
values). 

However, having a simple and interoperable way to request services is not 
useful if there is no way to know what a service looks like. UDDI and WSDL 
are recent standards that address this feature. The Universal Description, Dis- 
covery and Integration (UDDI) specification [5] describes a conceptual cloud of 
Web services and a programmatic interface that define a simple framework for 
describing any kind of Web service. The specification consists of several related 
documents and an XML schema that defines a SOAP-based programming proto- 
col for registering and discovering Web services. WSDL [6] is an XML format for 
describing network services as a set of endpoints operating on messages contain- 
ing either document-oriented or procedure-oriented information. The operations 
and messages are described abstractly, and then bound to a concrete network 
protocol and message format to define an endpoint. Related concrete endpoints 
are combined into abstract endpoints (services). WSDL is extensible to allow 
description of endpoints and their messages regardless of what message formats 
or network protocols are used to communicate, however, the only bindings de- 
scribed in WSDL documents describe how to use it in conjunction with SOAP 
1.1, HTTP GET/POST, and MIME. 

3 JavaCard and Its Integration in Information Systems 

The arrival of Java Card [7], and others open smart cards like Smart Card 
for Windows (SCW) and Multos was a kind of revolution in the smart cards 
world. Java Card technology allows applets written in the Java language to be 
executed on a smart card, within the Java Card Runtime Environment (JCRE), 
and provides a wide API to help developers to create applets. Both JCRE and 
APIs are modeled after the smart card ISO 7816 specification [8]. Java Card 
offers code sharing between applets, isolation with a sandboxing mechanism 
called applet firewall^ and comes with a cryptographic API. Java Card is the 
most widely accepted open smart card. This is firstly due to its symbiosis with 
an increasing Java computing world. The integration of Java Card Technology 
into mobile phone technology [9] is another key of its success. 



88 



Didier Donsez et al. 



As Scott Guthery titled in [10], Java Card was initially thought as a mobile 
platform for Internet Computing. Sometimes, like the example Java language 
originally dedicated to washing machines, technologies are not firstly used for 
what they have been though. Java Card is in this case, and four years after the 
first Java Card announcement it is not yet widely used for Internet purposes. The 
first applications of Java Cards were maybe loyalty ones. The application model 
was a client-server one, were the client is usually on the terminal where the card 
was plugged. Designing applications involving smart cards was originally not an 
easy task because the most part of the code was used to manage the communi- 
cation between the card and the client parts of the application through the card 
reader. Hopefully, nowadays this task is much more easier using frameworks like 
OCF [II]. 

Even if Java Cards can offer helpful services in an off-line mode, their use 
takes another dimension if plugged over a wired or wireless network. Java card 
can then be seen as a mobile physical agent serving its owner and representing 
him over distributed information systems. Open smart card is a young technol- 
ogy, and for the it does not yet play this role. However, as what Weiser called 
ubiquitous computing becomes a reality, mobile services provider is the most 
promising future for Multi- application smart cards. 

Interaction with Java Cards has been widely studied. All the mechanisms 
provided are however very similar because they consider the smart card as a 
server. Some researches have successfully turned the Java Card as a mobile Web 
server [12]. Close to the problematics of the WebSim project. The WebCard [13] 
is a Java Card applet implementing a lightweight IP/HTTP stack. WebCard is 
promising because it shows that a smart card can be seen as a traditional inter- 
net platform speaking IP. Morever, Schlumberger/Bull CPS recently announces 
the commercialization of an HTTP based card named iSimplify. The two pre- 
vious examples consider Java Cards like data servers, but another approaches 
try to integrate Java Cards as parts of distributed applications. A first example 
is the JC-RMI [14] technique that gives a Remote object view of embedded ap- 
plets. It goes further in easing smart card application design, enabling for Java 
Cards the well known RMI tools used to build classical Java distributed appli- 
cations. Here, applets as seen as Java remote objects. JC-RMI tools alleviate 
the burden of application designer by automatically generating stubs and skele- 
tons. These proxies transparently manages the communication protocol and just 
let distributed object access to applets. One step more is Java Card and JINI 
enclosure. Some work, done [15] or still in progress [14], intends to turn Java 
Card applets into JINI-based services. In such an approach, when a Java Card is 
plugged somewhere, its services are automatically registered and become avail- 
able for distributed applications that are able to discover them through JINTs 
lookup service. Once discovered, the services can be used as far as the smart 
card offering these services grant their access. Each step in open smart card in- 
tegration in distributed information systems lets the card plays a smarter role. 
In the future, we argue that smart cards should be much more interactive and 
not only passive servers [16]. 
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4 Toward a Generic, Dynamic, Asynchronous Access to 
Smart Card Services 

4.1 Motivations 

As the Java Card is becoming a more and more common computing platform, a 
simple and interoperable mechanism of interaction is needed in order to turn the 
embedded services available from any platform. Frameworks such as OCF [17] 
address such problem but reduce the platform range (here to Java-powered ones). 
Moreover, it might be interesting to assume service discovery and induced dy- 
namic operation invocation. For example, when a smart card becomes plugged 
in a CAD that is part of the user’s Personal Area Network (PAN), a daemon 
discovers what it is and what it can do. After this discovery time, the smart card 
authentication and privacy service is used to ensure trust in the user’s PAN. 

Aiming to ease integration of Java cards in a synchronous way is obvious. 
But, since smart cards are disconnected 99.9 percent of their lifetime, one has to 
consider this fact while using smart card in distributed applications. Some smart 
cards applications may be dedicated to work in an off-line mode. We give here 
two examples of such applications where the smart cards does not need to be 
permanently slotted. It can firstly be useful for a requester (which can be an ap- 
plication provider, a card issuer,. . . ) to be able to alert the card or make updates 
when needed (i.e. not only when the smart card is connected). Card Manage- 
ment Systems (CMS) and Application Management Systems (AMS) now take 
an important place in smart card world because controlling and managing a fleet 
and thousands issued smart card that embed several evolving applications is not 
an easy task. Ideally, an AMS should not wait for smart card insertion to decide 
for application update. A better way should be to asynchronously notify smart 
cards that a later version of a given application has been issued and to auto- 
matically upgrade it if necessary. As a smart card is not able for the moment 
to emit request to a reference server in order to poll for updates, using an asyn- 
chronous messaging platform should be the easiest way to update applet version 
or personalization info for thousand cards at the same time. Another example is 
agenda management. Such an application does not need strong synchronization. 
The differents partners who want to meet do not need to wait each other to 
request an appointment. In this case, a software agent (representing the card) 
takes into account appointment requests when the card is disconnected. When 
the card slots again, waiting appointments are transmitted to the card service 
that confirms or cancels them. 



4.2 Architecture and Prototype 

In order to turn embedded services available to remote hosts, some requirements 
have to be fulfilled. We have to separate the transport part on the gateway from 
services requests on slotted cards. We have designed the architecture presented 
on Figure 4 to plug several transport layers on one side and several layers called 
SPI (Service Provider Interface) on the other side. SPIs introspect and invoke 
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applications installed on slotted cards while transport layers exchange SOAP 
messages between clients and the gateways. The SOAP messages encapsulate 
the services requests and the belonging responses (that can be error messages in 
case of request mismatch) into XML messages transported from point to point 
(i.e. from remote host to a reference host for the smart card). In the case of 
synchronous requests, the transport protocol is mainly HTTP. 

In the case of asynchronous requests, the SOAP messages are transported by 
SMTP/POP3 protocols or by a Message Broker that is JMS-compliant in the 
prototype. The by-MOM request requires message queues : one permanent queue 
per card and one temporary queue per client. The client firstly sends a SOAP 
message to the card queue. Next time the card is slotted, the gateway reads 
queued messages and invokes corresponding applets in the card. Responses are 
sent back to the client’s temporary queue. In a similar manner, the SMTP/POP3 
invocation requires one mailbox per card and one temporary mailbox for the 
client. The client firstly sends a SOAP message to the card mailbox through 
SMTP. Next time the card is slotted, the gateway downloads all received mes- 
sages and invokes corresponding applets in the card. Responses are sent back to 
the client’s temporary mailbox. 



Asynchronous Requesl/Reply Transport 



Synchronous Request/Reply Transport 
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Fig. 4. Gateway Architecture 



The second part of the gateway provides a generic mechanism to enable 
smart card services discovery as well as to invoke operations. We separate the 
concept of service from the one of card applet. A service offered by an open smart 
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card can involve one or several applets (for example, a gambling service can be 
provided using a dedicated applet using a banking one for payment issues). 
The two previous generic functions are done by a Service Provider. The Service 
Provider is dependent of the card type and fits SOAP messages according to 
the card profile. The SPI is loaded as the card is slotted. The first task of 
SPIs is to manage card introspection and services descriptions. Turning services 
requests dynamic means that the embedded services interfaces must be known 
or discovered at invocation time. So, in other words, service introspection has to 
be provided. 

We propose two different ways to get introspection. The first way is to store 
services descriptions on smart cards or on remote repositories (see Figure 5, 
left). Due to interoperability issues, descriptions are represented according to 
an XML DTD grammar that is closed to WSDL and UDDI. When the card is 
slotted, the SPI gather AIDs (Application IDentifiers) of installed applications. 
These AIDs are used by the SPI to retrieve services descriptions from a remote 
repository. Descriptions are used to transform SOAP messages from/to APDU 
commands (parameters marshalling, . . . ). In this approach, services descriptions 
can be registered and replicated on several servers over the Web. Descriptions 
can be also cached locally by the gateway on which a card is slotted. 

The second way consists to store services descriptions on the card itself (see 
Figure 5, right). This requires to add introspection facilities to the card. In the 
case of the Java Card, we propose to install a repository application that stores 
services descriptions. This application also stores the address and associated cre- 
dentials of the card mailbox and queue. The gateway uses this information to 
get SOAP invocation messages and to invoke operations on the card. The repos- 
itory is updated by the application installer when applications are installed or 
removed. This repository function should be one of function of the next genera- 
tion smart card operating systems. This second approach is better in an off-line 
context since it avoids to get descriptions from the network. 

A prototype been developed for testing purpose is based on the use of a 
GemXPresso 211 Java Card from Gemplus. The services invocations and re- 
sponses are transported either synchronously with HTTP or asynchronously 
with a JMS-compliant MOM. The HTTP prototype is based on a subset of 
classes from Apache/ SOAP package and Jakarta/Tomcat for servlet execution 
platform. The MOM prototype is based on JORAM [3], an open source im- 
plementation of JMS specification. This prototype has validated the previously 
presented architecture. 

As described on Figure 5, a card-side SOAP proxy (implemented by a servlet) 
provides introspection and invocation facility. It relies on the use of OGF to man- 
age readers and cards access. The discovery mechanism is implemented inside 
the card by the way of the Introspection applet that manages XML-based de- 
scriptions. The test application consists of a distributed client based on a Web 
interface that connects to a targeted Java Gard, dynamically discovers inside 
applications (here, an agenda and a loyalty application) and invokes operations 
on them. 
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Fig. 5. Providers for Java Card using on-the-web application description (a) and 
in- card application description 



5 Conclusion and Further Work 

The objective presented in this paper is relevant with regard to necessities in 
communications. More and more services are available on the Internet as well 
as on mobile telephony. Smart cards take a more and more important place in 
services offering over these networks. To seamlessly integrate multi- application 
smart cards in order to turn them in common object-oriented execution platforms 
(regarding to client applications), interoperable operation invocations must be 
provided. As smart cards are not so frequently connected, the use of asyn- 
chronous messages can open new perspectives. In this paper, we have presented 
how to enable interoperability and asynchronism for distributed applications 
that involve multi-applications smart cards. To achieve this goal, we take bene- 
fits of SOAP and MOMs technologies. A software architecture has been defined 
in order to enable SOAP-based operation invocations for smart cards. A SOAP 
proxy provides introspection facilities that, combined with an on-card introspec- 
tion mechanism, makes able distributed clients to dynamically discover and use 
the embedded services offered. We also define a MOM layer which, placed on 
top of SOAP, enables asynchronous invocations. Although we focus on the Java 
Card case, the approach and platform we describe can be easily generalized to 
others multi- applications smart cards such as the Smart Card for Windows [18] 
or Mult os [19]. 
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Appendix: SOAP/HTTP Envelopes for a Smart Card 
Loyalty Application 

Invocation 

POST card : gcr410_coml : loyalty/invoke HTTP/1.1 
Content-Type: text/xml; charset="utf-8" 

Content-Length: 478 

SOAPAction: "cardl23456789 : loyalty/invoke" 

<S0AP-ENV : Envelope xmlns : SOAP-ENV="http : //schemas . xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www . w3 . org/1999/XMLSchema-instance" 
xmlns : xsd="http : //www . w3 . org/1999/XMLSchema" > 

<SOAP-ENV:Body> 

<loy : GetBonus xmlns : loy="http : //schemas . loyaltycard . org/" 

SOAP-ENV : encodingStyle="http : //schemas . xmlsoap . org/soap/encoding/"> 
<service xsi : type="xsd : string">ACME</service> 

</loy : GetBonus> 

</SOAP-ENV:Body> 

</S0AP-ENV : Envelope> 



Response 

HTTP/ 1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 

Content-Length: 484 

<S0AP-ENV : Envelope xmlns : S0AP-ENV="http : //schemas . xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www. w3 . org/ 1999/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/ 1999/XMLSchema" > 

<S0AP-ENV:Body> 

<loy : GetBonusResponse xmlns : loy="http : //schemas . loyaltycard . org/ " 

SOAP-ENV : encodingStyle="http : //schemas . xmlsoap . org/soap/encoding/"> 
<bonus xsi : type="xsd: int ">1900</bonus> 

</loy : GetBonusResponse> 

</S0AP-ENV:Body> 

</S0AP-ENV : Envelope> 
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Abstract. This paper presents an operational semantics for a subset 
of Java Card bytecode, focussing on aspects of the Java Card firewall, 
method invocation, field access, variable access, shareable objects and 
contexts. The goal is to provide a precise description of the Java Card fire- 
wall using standard tools from operational semantics. Such a description 
is necessary for formally arguing the correctness of tools for validating 
the security of Java Card applications. 



1 Introduction 

Java Card is being promoted as a high-level language for programming of multi- 
application smart cards. The high-level nature of the language should ease the 
programming and the reasoning about such applications. Java Card keeps the 
essence of Java, like inheritance, virtual methods, overloading, etc, but leaves 
out features such as large primitive data types (long, double and float), char- 
acters and strings, multidimensional arrays, garbage collection, object cloning, 
the security manager, etc. (see the specification [1] and also [8]). Furthermore, 
given the security-critical application areas of Java Card, the language has been 
endowed with an elaborate security architecture. 

Central to this architecture is the Java Card firewall. Applets installed on 
the card are separated by a firewall that prevents one applet from accessing 
objects owned by another applet. Shareable objects and interfaces are used to 
provide communication between otherwise separated applets. A limited form of 
stack inspection allows a server applet to know the identity of the client that 
requested a particular service. These mechanisms (that will be further detailed 
in section 2) facilitate the design of secure applications but do not in themselves 
guarantee security. They do, however, offer the possibility of formal verification 
of the security of an application using tools from semantics and static program 
analysis. The purpose of this paper is to give a formal semantic description of 
the Java Card firewall. The interest of such a description lies in its use as a 
foundation for designing and proving static analysis methods for verifying the 
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security of a multi- application Java Card, but for lack of space we do not detail 
this here. 

The paper is organised as follows. In section 2 we give a description of the 
central security features of Java Card 2.1.1. This is followed by the definition of 
semantics domains in section 3 and the operational semantic of selected byte- 
code in section 4. In section 5, we discuss related work. 

2 The Java Card Firewall 

The Java Card platform is a multi-application environment in which an applet’s 
sensitive data must be protected against malicious access. In Java, this protection 
is achieved by using class loaders and security managers to create private name 
spaces for applets. In Java Card, class loaders and security managers have been 
replaced with the Java Card firewall. The separation that is enforced by the 
firewall is based on the package structure of Java Card (which is the same as 
that of Java) and the notion of contexts. 

When an applet is created, the JCRE gives it a unique applet identifier (AID) 
from which it is possible to retrieve the name of the package in which it is defined. 
If two applets are instances of classes coming from the same Java Card package, 
they are said to belong to the same context (which we identify by the package 
name). In addition to the contexts defined by the applets executing on the card, 
there is a special “system” context, called the JCRE context. Applets belonging 
to this context can access objects from any other context on the card. Thus, the 
set Contexts of contexts can be defined by: 

Contexts = {JCRE} U {pckg : pckg is a legal package name} 

Every object is assigned a unique owner context viz., the context of the applet 
that created the object. A method of an object is said to execute in the owner 
context of the object^. It is this context that decides whether an access to another 
object will succeed. The firewall isolates the contexts in the sense that a method 
executing in one context cannot access any fields or methods of objects belonging 
to another context. 

There are two ways in which the firewall can be circumvented: via JCRE entry 
points and via shareable objects. JCRE entry points are objects owned by the 
JCRE that have been designated specifically as objects that can be accessed 
from any context. The most prominent example is the APDU buffer in which 
commands sent to the card are stored. This object is managed by the JCRE 
and in order to allow applets to access this object, it is designated as an entry 
point. Other examples include the elements of the table containing the AIDs 
of the applets installed on the card. Entry points can be marked as temporary. 
References to temporary entry points cannot be stored in objects (this is enforced 
by the firewall). 



^ In the case of static call, the execution is in the caller’s context. 
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Two applets in different contexts may want to share some information. For 
that, Java Card offers a sharing mechanism, called shareable ohjeets^ that gives 
limited access to objects across contexts. An applet can allow access to an ob- 
ject’s methods from outside its context (it is impossible to share fields) by using 
a shareable interface that is, an interface which extends javacard. framework. - 
Shareable. In this interface, the applet gives the list of the method’s signatures 
that it wants to share. The class of the object to be shared must implement this 
interface. The “server” applet must define a method, getShareablelnterface- 
Object. This method is called when an applet is asked to provide a shared ob- 
ject. It is passed as parameter the AID of the “client” applet which requested 
the shared object. This allows different objects to be shared with client applets. 

In the following section, we give a small example to illustrate these sharing 
mechanisms. 

2.1 A Simple Scenario 

We have 3 applets: Alice, Bob and Charlie, each belonging to a different 
context. Alice implements a shareable interface MSI and she is prepared to 
share an object MSIO with Bob (MSIO is an instance of a class that im- 
plements MSI). When Alice receives a request for sharing (using the method 
getShareableInterfaceObject, she verifies that the caller is Bob. If it is Bob, she 
returns the MSIO, otherwise she returns null (see also section 4). 
public class Alice extends Applet implements MSI { 

public Shareable getShareableInterfaceObject (AID client, byte param){ 
if (client . equals (BobAID, (short) 0 , (byte) BobAID . length) == false) 
return null; 
return (this) ; } } 

Using the method JCSystem.getAppletShareableInterfaceObject, Bob asks for 
a shareable object from Alice. Assume now that Bob (inadvertantly) leaks a 
reference to MSIO to the third applet Charlie^. With it, Charlie can access the 
same methods as Bob. 
public class Bob extends Applet { 
public static MSI AliceObject; 

AliceObject = 

(MSI) JCSystem.getAppletShareableInterf aceObject (AliceAID, (byte)O) ; } 

public class Charlie extends Applet { 
private static MSI AliceObject; 

AliceObject = Bob . AliceObject ; 

// The method void foo () exists in MSI 
AliceObject . f 00 () ; } 

Alice has some doubts about Bob so she decides to verify, at each access to 
one of her shared methods, the identity of the caller. In this case Charlie can’t 
access MSIO anymore. 

^ for example, by storing the reference into a public static field (there are other more 
subtle ways in which this can happen) 
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public class Alice extends Applet implements MSI { 
public void foo () { 

// The caller is Bob? 

AID client = JCSystem. getPreviousContextAID () ; 

if (client . equals (BobAID, (short) 0, (byte) BobAID . length) == false) 
ISOException.ThrowIt (SW_UNAUTHORIZED .CLIENT) ; 

... // OK, the caller was Bob } } 

2.2 Limitations of the Firewall 

As illustrated by this example, Java Card has a limited form of the stack in- 
spection mechanism that underlies the Java 2 security architecture. The Java 2 
checkPermission instruction verifies whether all callers on the call stack have a 
specific permission (e.g. to write a file in a given directory). Java Card contains 
a mechanism for knowing from which context a method was called but there is 
no mechasnism for obtaining the identity of all the callers. More precisely, an 
applet can get a description of the last context switch that took place, by calling 
the method getPreviousContextAID. (Notice that this context switch could have 
happened several levels down in the call stack.) In the example, Alice does not 
know whether the call made by Bob is in turn a result of Bob being called by 
some other applet. Neither can she know what Bob will do with the result of 
the call. This is problematic since an object is only marked as shared, not with 
whom it is supposed to be shared. Thus, while the firewall can serve to prevent 
direct information flow, further program analysis is required in order to verify 
that all information flow of the application respects a given security policy. 

3 Semantic Description of the Java Card Firewall 

In the following we describe the semantic domains of a modified version of Java 
Card bytecode. Rather than a stack-oriented bytecode we shall be working with a 
“three-address” bytecode where arguments and results of a bytecode instruction 
are fetched and stored in local variables instead of being popped and pushed 
from a stack. This format is similar to the intermediate language used in the 
Java tool Jimple [17]. Furthermore, we assume that the constant pool has been 
expanded i.e. that indices into the constant pool have been replaced by the 
corresponding constant. For example, the bytecode instruction invokevirtual 
takes as parameter the signature of the method called, rather than an index into 
the constant pool. The transformation of code into this format is standard and 
straightforward. 



3.1 Notation 

The term ^(X) denotes the power set of X.* fPfXj = {S \ S C X}. A product 
type X = AxBxC is sometimes treated as a labelled record: with an element 
X of type X we can access its field with the names of its constituent types (x.A, 
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x.B or x.C). A list can be given by enumeration of its elements: xi :: • • • :: 
Given a list v we can access one of its element by its position in the list {v{i) 
for the ith element). And finally, we can concatenate two lists: {xi :: • • • :: Xn) ::: 
{xm :: • • • :: Xp) = :: Xm :: • • • :: Xp. We denote, by X*, the type 

of finite lists, whose elements are of type X. We use the symbol ^ to form the 
type of partial functions: X ^ Y. We can update a function / with a new value 
V for an argument x: g := f[x ^ v]. We (ab)use the same notation for objects: 
the object obtained from object o by modifying field / to have value v is written 
o[f v\. 



3.2 Semantic Types 

Our semantic domains follow the same structure as the domains defined by 
Bertelsen [5,6]. 

Before introducing the representation of the different elements, we define 
some basic types. Jdc, Idi^ Idf and I dm are the types of qualified name of a 
package, a class, an interface, a field and a method, respectively^. When we want 
to talk about a class or an interface name, we can use the set Idd {Idd = Idc U 
Idi). Idy is the type of (unqualified) names of variables. We assume furthermore 
a set Pc of program counters. A program counter identifies an instruction within 
the whole class hierarchy (i.e. it is relative to a class hierarchy and not just a 
method). We assume a set Label which represents the different labels used with 
a jump instructions. 



General Types We use types to stand for abstract primitive values. For ex- 
ample, byte instead of 12. A type can be an array type (type between square 
brackets), or a simple type where a simple type is a Primitive or the name of a 
class or of an interface (Idd)- 

Primitive = { boolean, short, byte, int } 

Type = ^[^SType^]^ U Stype 
SType = Primitive U Idd 



Classes A class or an interface descriptor consists of the set of the associated 
access modifiers (T (Modd)^)^ the name of the class or interface (Idd), the name 
of the direct superclass or the names of direct superinterfaces (Ext), the name 
of the interfaces that the class implements (Imp)^ the name of its package (/c?p), 
field declarations (F/d), method declarations and implementations (Mtd). A class 
must have a superclass, the default being java. lang. Object, but an interface can 

^ The qualified name of an entity is the complete name. For a class, it is p.c where p 
is the name of the package and c the (unqualified) name of the class. For a method 
(c.m) or a field (c./), it is the qualified name of the class and the (unqualihed) name 
of the method or field. 

^ The access modifier Interface is used to specify that the declaration is for an 
interface. 
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have zero, one or more super interfaces. Only a class can implement an interface, 
so for an interface this field is the empty set. 

The fields of a class are described by a map from field names (Idf) to a set 
of access modifiers {y(Modf )) together with a type descriptor {Type). The type 
descriptor defines what type of values can be stored in the field. 

DesCci = y(Modci) x Idd x Ext x Imp x Idp x Fid x Mtd 
Model = { Public, Package, Final, Abstract, Shareable, Interface } 

Ext = ide U T(Idi) 

Imp = T(Idi) 

Eld = Idf ^ Descf 
Descf =T(Modf) x Type 

Modf = { Public, Package, Private, Protected, Final, Static } 3 

Methods The methods are described by a map that to a method signature 
{Sig) associates a method descriptor (Desem)- This structure consists of the set 
of the associated access modifiers {T (Modm)), the code of the method {Code)^ 
a description of the formal parameters (Param) and the local variables of the 
method ( Varl). A signature is the name of the method {Idm) and the list of type 
descriptors for its parameters {Type""). Code is a list whose elements consist of 
a program counter value (Pc) and the instruction at this address {Byteeode). 
The set of local variables is the list of all variable names {Idy) with their type 
descriptor (Type). 

Mtd = Sig Desem 
Sig = Idm X Type"" 

Desem = T(Modm) x Code x Param x Varl 
Modm = { Public, Package, Private, Protected, Static } 

Code = Inst* 

Inst = Pe X Byteeode \ Pe x Byteeode x Label 
Varl = (Idy X Type)* 

Param = (Idy x Type)* 

For this paper we consider a small set of bytecodes that is sufficient for 
illustrating the different features of the semantics. In the following, NT and T 
range over local variables. The invoke virtual instruction takes as argument a 
fully qualified method name, indicating the point of declaration of the method. 
The explainations of these intructions are given in section 4.2. 

Byteeode = NT := getstatic C.f 
I putfield C.f T\ T 2 

I NT := invokevirtual C.m Tq Pi • • • T^ Si::- • - .'.'Sn 
I goto label 
I NT := new C 
I NT := invokestatic getAID 
I NT := invokestatic getPrevCtx 
I NT := invokestatic getASIO T\ T 2 
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3.3 The Run-Time State 

This section defines the run-time values used in the semantics. We are primarily 
interested in modelling the object structure and ownership so we abstract prim- 
itive values such as booleans and integers to their type. In addition to the values 
already introduced we have a set, Ref, of references for modelling the heap of 
objects. A particular element Null G Ref denotes the undefined reference. We 
introduce two kinds of reference, Ref (respectively Ref a) can point to class in- 
stances Ohji (respectively array instances Obja) and the union of them with Null 
is Ref 



Ownership The notion of ownership in Java Card is very clear, an object 
is owned by the active applet at the moment of its creation. We extend the 
definition of an owner with the context (package) of its creation. We model this 
notion with a pair (Paekage, Applet). 

Owner = Idp x Ref 

The owner of an applet is the applet itself. 



Values 

Value = Ref U Primitive 
RValue = Objeet U Primitive 
Objeet = Obji U Obja 

Obji = Idci X Owner x JCREep x tJCREep x Eldv 

Eldv = Id f ^ Value 

Obja = SType j’ x Owner x JCREep x tJCREep x global x Elt 
Elt = y (Value) 

We have three kinds of values: class instances, arrays and primitive values 
(such as bytes and booleans). A class instance contains the name of the class, the 
owner of this instance, boolean flags indicating whether or not it is a JCRE entry 
point and a temporary JCRE entry point (c/. section 2) and the set of fields. 
The set of fields maps a field name to a value. 

An array instance is described by the type of its elements, the owner, the 
information about being an entry point or not, a flag indicating whether the 
array is global or not and finally the set of its elements. 



The State With these types, we can define the state used in the semantics. 
A state consists of a call stack of frames, the memory and the class hierarchy. 
The latter is part of the run-time state because it is used to store the values 
of static fields. We write the call stack as a sequence of frames such that the 
currently active frame appears as the first element of the sequence. 
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State = Frame^ x Mem x Ed 
Frame = Inst x Ref x Locals 
Locals = Idy Value 
Mem = Value RValue 
Ed = Idd Descd X FldS 
FldS = Idf Value 

The current frame contains the current instruction and a reference to the 
object on which the method currently executing has been invoked. This object 
represents the currently active context. An element of the set Locals maps a local 
variable to its value. The memory (also called the heap of objects) is modelled 
by a map from references to values. The class hierarchy is represented as a map 
that to a class or an interface name associates its descriptor and its static fields. 



AIDs and the Table of Installed Applets The JCRE keeps a table record- 
ing the applets installed on the card. These applets are identified by an applet 
identifier, an AID. An AID is an object of class AID containing a byte array with 
a number that identifies the applet together with a method for testing whether 
two AIDs represent the same number. With a reference to an AID, we can find 
a reference to the corresponding applet instance through the table Applet Rhl of 
installed applets: 

Applet Abl : Ref Ref. 

Were we to model the dynamic installation of applets this table would have to 
be made part of the state but we do not consider this here. 



3.4 Auxiliary Functions 

We follow Bertelsen [5,6] and define a number of functions that abstract the 
syntactic structure of a list of bytecodes. 

Succ : Inst ‘F{Inst) 

Find : Label Inst 
First : DesCm Inst 

The flow of control inside a method is modelled by the function Succ that for each 
instruction yields the set of instructions that can follow in the execution. The 
need for returning a set of instructions is due to the fact that we have abstracted 
away all primitive values; in particular, the semantics will not be able to evaluate 
the value of the condition in a branching statement. The function Find permits 
us to find an instruction with a given label. Finally, the function First takes a 
method descriptor and returns the first instruction of this method. 

The function Lookup models the dynamic resolution of virtual method calls. 
It takes as arguments the signature of a method, the dynamic class of the object 
on which the method is invoked, the class in which the method is declared and 
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the class hierarchy. It returns the method descriptor of the implementation of 
the method designated by the signature.^ 



Lookup : Sig x Idd x Idd x Ed DesCm- 

The function ImpShareable? determines if the class of an object implements 
a Shareable interface. This function is recursive on the field Imp of the class. 

Imp .Shareable? : — > boolean. 

The function Ext. Shareable? determines if an interface extends the interface 
Shareable. This function is recursive on the field Ext of the interface. 

Ext. Shareable? : I di ^ boolean. 

Initialisation The function Init.Var constructs a function that maps the local 
variables of a method to their initial values. 

Init.Var : Param x Value'' x Varl Loeals. 

It takes the name and the descriptor of the formal parameters, the value of the 
actual parameters and the name of local variables of the frame to be constructed. 
The result is a function that maps the formal parameters to the value of the 
corresponding arguments and is default on local variables. The default value for 
a object and an array is Null. For a primitive, the default value is type of the 
primitive value. 

Similarly, when creating a new object instance, we use a function Init.Fields 
to prepare the set of instance fields for a specified class and all of its superclasses: 

Init. Fields : Idd Fldv. 

It takes the name of the class and returns a function in which a field name 
maps the default value for its type (the default value is the same as defined for 
Init. Var) . 

4 Operational Semantics for Instructions with the 
Firewall 

In this section we give an operational semantics for a small subset of Java 
Card instructions. The main feature that distinguishes this semantics from a 
Java bytecode semantics is the modelling of the Java Card firewall. The rules 
for instructions that can violate the firewall include an extra hypothesis that 
formalises when the instruction can be executed without raising a security ex- 
ception. 

^ In this paper we do not describe any further the details of dynamic method lookup 
in Java(see [11, section 15.12] and [9]). 
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4.1 Firewall Checks 

The checks made by the firewall are formalised through a collection of predicates. 
Covering all bytecode instructions requires eight different predicates. We give the 
exact formula only for the two predicates used in this paper. 

CheckVirtual? This check is performed during a call to a virtual method. 
CheckVirtual? : Object x Object boolean. 

For (01,02) G Object x Object, the access is authorized if and only if the 
context represented by 0\ is the context of the JCRE {oi. Owner. I dp = JCRE) 
or if the contexts of oi and 02 are the same {oi. Owner. I dp = 02. Owner. I dp) or 
if the object 02 is global {02. global) or if the object 02 is a JCRE entry point 
{o2.JCREep). 

CheckVirtual? (01,02) = 

(oi.Owner.Idp = JCRE) V (o\.Owner.Idp = 02. Owner. Idp) V (02. global) V 
(o2.JCREep) 

CheckPutjield? This check is performed when storing a value in a field. 
CheckPutjield? : Object x Obji x RValue boolean. 

For (oi,02,v) G Object x Obji x RValue, the access is authorized if and only 
if the context represented by 0i is the context of the JCRE {oi.Owner.Idp = 
JCRE) or if the contexts of 0\ and 02 are the same {oi.Owner.Idp = 02. Owner. - 
I dp) and if the value is not a global object (-1 v. global) and is not a temporary 
JCRE entry point (-1 v.tJCREep). 

CheckPutjield? (oi,02,v) = 

(oi.Owner.Idp = JCRE) V ((oi.Owner.Idp = 02.Owner.Idp) A (^ v. global) A 
V.tJCREep)) 

Check A Load? This check is performed when read access is made to an array. 
Check ALoad? : Object x Obja boolean. 

For (o,a) G Object x Obja, the access is authorized if and only if the context 
represented by o is the context of the JCRE {o. Owner. I dp = JCRE) or if the 
contexts of o and a are the same {o. Owner. I dp = a. Owner. I dp) or if the array 
represented by a is a global array {a. global). 

The instruction arraylength performes exactly the same check, so for this 
instruction we use the CheckALoad? predicate. 

Check A Store? This check is performed when storing an element in an array. 
CheckAStore? : Object x Obja x RValue boolean. 

For (o,a,v) G Object x Obja x RValue, the access is authorized if and only if 
the context represented by o is the context of the JCRE {o. Owner. I dp = JCRE) 
or if the contexts of o and a are the same {o. Owner. I dp = a. Owner. I dp) or if the 
array represented by a is a global array {a. global) and if the value not represents 
a global array (-1 v. global) or a temporary JCRE entry point (-1 v.tJCREep). 
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CheckClass? This check is performed during a cast or an instance.of check. 
CheckClass? : Object x Object x Idi boolean. 

For (oi,02,Id) G Object x Object x the access is authorized if and only 
if the context represented by 0\ is the context of the JCRE {oi.Owner.Idp = 
JCRE) or if the contexts of 0i and 02 are the same {oi. Owner. I dp = 02. Owner. - 
I dp) or if the object 02 is global {02. global) or if the object 02 is a JCRE entry 
point (o2.JCREep) or if the object’s class implements a Shareable interface 
{Imp .Shareable? (o2.Imp)) and if the object being cast into or an instance of an 
interface that extends Shareable {Ext.Shareable? (Id)). 

CheckGetfield? This check is performed when reading access on a field is made. 
CheckGetfield? : Object x Obji — > boolean. 

Eor (01,02) G Object x Obji, the access is authorized if and only if the context 
represented by o\ is the context of the JCRE {o\. Owner. I dp = JCRE) or if the 
contexts of oi and 02 are the same {o\. Owner. I dp = 02. Owner. I dp). 

Checkinterface? This check is performed during a call to an interface method. 
Checkinterface? : Object x Obji x Idi boolean. 

Eor (oi,02,Id) G Object x Obji x Idi, the access is authorized if and only if the 
context represented by oi is the context of the JCRE {o\.Owner.Idp = JCRE) 
or if the contexts of 0i and 02 are the same {oi. Owner. I dp = 02. Owner. I dp) 
or if the object 02 is a JCRE entry point {o2.JCREep) or if the object’s class 
implements a Shareable interface {Imp. Shareable? (o2.Imp)) and if the interface 
being invoked extends Shareable {Ext.Shareable? (Id)). 

CheckPutstatic? This check is performed when storing a value in a static field. 
CheckPutstatic? : Object x RValue boolean. 

Eor (o,v) G Object x RValue, the access is authorized if and only if the 
context represented by o is the context of the JCRE {o. Owner. I dp = JCRE) or 
if the value is not a global array (-1 v. global) and is not a temporary JCRE entry 
point (-1 v.tJCREep). 



4.2 The Semantics 

The present semantics does not take visibility into account. Although the model 
has enough information to deal with visibility modifiers, we omit this for brevity. 

Concerning the Java Card API, we only consider methods directly related 
to the firewall. These are getAppletShareablelnterfaceObject, getShareable- 
Interf aceObject, getAID and getPreviousContextAID. The static method get- 
AppletShareablelnterf aceObject that belongs to the JCSystem package is called 
by a client when it wants to obtain a shareable object from a server applet 
(cf. Section 2.1). The JCRE in turn invokes the method getShareablelnterf ace- 
Object that returns a shareable object based on the identity of the client. Thus, 
the modelling of a call to get Applet Shareablelnterf aceObject is a combination 
of a static and a virtual method call. The call to getShareablelnterf aceObject 
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is made directly by the rule of getAppletShareablelnterfaceObject, the invoke- 
static is transformed into a invokevirtual if the call to getShareablelnterf ace- 
Object is possible. The semantics contains a rule that treats the invocation 
of this method separately. Similarly, there is a separate semantic rule for 
the invocation of the two static methods of the JCSystem package get AID and 
getPreviousContextAID for accessing the AID of the applet that owns the cur- 
rently executing object and the AID of the context in action before the switch to 
the current context, respectively. In addition, we give semantics to five bytecodes: 
getstatic, putfield, invokevirtual, goto and new. 

getstatic The getstatic instruction loads a value stored in a static class or 
interface field and stores it in a local variable. 

/ = {pc^NT := getstatic C./) 
y/ = V[NT ^ E,i{C).FldS{C.f)] 

r e Succjl) 

{{I, r, V) :: A, mem, Ed) => ((/', r, V') :: A, mem, Ed) 

The class or the interface C must have a descriptor in Ed . The field C.f must 
exist in the set of static field of C. Then the value of the field {Ed{C).EldS{C.f)) 
is loaded and stored into variable NT. 

putfield The putfield instruction loads a value from a local variable and stores 
it into an instance field. 

/ = (pc, putfield C.f Ti T2) 
o = mem(y (Ti)) 
g = o.Eldv[C.f ^ V{T2)] 
o' — o[Eldv g] 
mem' = mem\y {Ti) o'] 

r G Succ{I) 

[ CheekPutfieldl{mem{r)^mem{V{Ti))^mem{y {T2))) ] 

((/, r, V) :: A, mem, Ed) ((/', r, V) :: A, mem', Ed) 

The value stored in T\ must be a reference to a class object. This object 
must have a field C.f. Then the value stored in T2 is stored in the field. 

invokevirtual The invokevirtual instruction makes a call to an instance method. 

/ = (pc, NT := invokevirtual C.m To Ti • • • T^ S'! Sn) 

dese = Lookup {{m, Si :: • • • :: Sn),raem{V{To)).Idd,C, Ed) 

V' = Init-V ar{dese.Param^V {Tfi) V (Tn) , desc.V arl) 

I' = First{dese) 
r' = V{To) 

[ Cheek Virtual? {mem{r),mem{V{To))) ] 

((/, r, V) :: A, mem, Ed) => ((/', r', V') :: (/, r, V) :: A, mem, Ed) 

The value stored in Tq must be a reference to a class instance. We search for the 
implementation of the method called using the function Lookup. We construct 
the new list of local variables with the variables set to the actual parameters. 
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goto The goto instruction makes a jump to an instruction labelled label 

I = (pc, goto label) 
r = Find(label) 

((/, r, V) A, mem, Ed) ^ ((/', r, V) A, mem, Ed) 
new The new instruction creates a new object in memory. 

I = {pc,NT := newC) 

O = {C, mem{r) .Owner, false , false, I nit -Fields {C)) 

R G Ref \ dom{mem) 

V' = V[NT ^ R] 
mem' = mem[R O] 

r G Succ{I) 

{{I,r,V) :: A, mem, Ed) => {{V ,r,V) :: A, mem', Ed) 



A new object of class C is created in the memory with the flags for entry point 
and temporary entry point set to false. A reference to this object is stored in 
the variable NT. 

get AID 

I = {pc, NT := Invo'k.esta.tlc JC System. get AID) 

V' = ^[A^T mem{r) .Owner .AI D] 

I' G Succ{I) 

{{I, r, V) :: A, mem, Ed) => {{!', r, V) :: A, mem, Ed) 

The AID of the currently active applet is the AID of the owner of the current 
object. A reference to the current object can be retrieved from the frame as r. 

getPrevious Context A ID 

I\ = {pc, NT := lirsrokestBXlc JC System. get PreviousContext AID) 

Vi G {2, • • • , n — 1}, Mem{ri).Owner.Idp = mem{ri) .Owner.Idp 
mem{rn)-Owner.Idp ^ mem{r\).Owner.Idp 
V' = ^[A^T mem{rn) ‘Owner. AID] 

r G Succ{h) 

((-^1 5 ^ •• ' ' ' •• kn) •• A, mem, Ecf) 

{{I',ri,V') :: (/2,r2,IV) {In^Vn^Vn) :: A,mem,Eci) 

The previous context is found by searching down the call stack for the most 
recent frame whose current object has an owner context that differs from the 
owner context of the current object on top of the call stack. If none such is found, 
Null is returned. 
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getAppletShareableInterfaceObject 

I = {pc, NT := invokestatic JC System, get Applet ShareableInterfaceObject 
T 1 T 2 ) 
server = V{Ti) 
server G Dom{AppletJtbl) 
class = M em{ AppletTbl {Server)). I dci 

desc = Lookup{{getShareableInterfaeeObjeet, kTD :: byte), c/ass, Applet, 
client = mem{r). Owner. AID 
I' = First{desc) 
r' = AppletJbl {server) 

V' = I nit Alar {desc. Par am, r' :: client :: mem{V {T 2 )) , desc.V arl) 

((/, r, V) :: M, mem, Eci) ((/', r', "E') :: (/, r, 1/) :: M, mem, Eci) 

This method is called by the elient to get the server applet’s shareable ob- 
ject. Although a static method call, it functions as a virtual call of the method 
getShareableInterfaceObject of the server. If the firewall conditions are not re- 
spected, the result is Null. 

5 Related Works 

There are several works on a formal semantics for Java [4,10] . The Bali project [2] 
provides an axiomatic semantics for a substantial subset of Java and Java Card 
but does not give an axiomation of the firewall. To formalize the language, 
they use a Hoare-style calculus [18,19]. All definitions and proofs are done for- 
mally with the theorem prover Isabelle/HOL. The resulting proof system can 
be proved sound, is easy to use, and complete. A similar goal is pursued in the 
Loop project [3], where they develop an interface specification in JML of the 
Java Card API [14] and provide proofs that the current Java Card API classes 
satisfy these interface specifications [15]. The more comprehensive semantics was 
proposed by Bertelsen [5] and was taken as the starting point for the present 
work. This semantics models the stack-based Java bytecode. Our choice of pass- 
ing to a variable-oriented language means that we no longer have an operand 
stack in the frames. Moreover, we had to add certain attributes to the run-time 
structures to keep track of the owner of objects, whether they are entry points 
ete. Pusch has formalised the JVM in HOL [16]. Like us, she considers the class 
file to be well- formed so that the hypotheses of rules are just assignments. The 
operational semantics is presented directly as a formalisation in HOL, whereas 
we have chosen (equivalently) to use inference rules. Several works have focussed 
on formalising aspects of the Java Card firewall. Motre has formalised the firewall 
in the B language [13]. She transforms the informal specification into an abstract 
machine which can then be refined into an actual implementation. Each oper- 
ation of this machine corresponds to a specific object access. This description 
of the firewall provides a formal description of the security policy as defined in 
JCRE specification [12] and provides a reference implementation of the firewall. 
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She formally demonstrates that the firewall verifications of bytecodes are suffi- 
cient to fulfil the security policy and to ensure the memory integrity (that only 
an authorised operation can access the memory) . Bieber et al. [7] propose a veri- 
fication technique based on model checking for detecting illegal information flow 
between Java Card applets. They associate a level with each applet and the legal 
flow between applets are given as a lattice of levels. Each applet is abstracted 
into a set of call graphs. All call graphs that do not include an interface meth- 
ods are discarded (the sharing mechanism uses interface method). All values of 
variables are abstracted by computed levels, a variable having the level of the 
applets which use it. They give an invariant that is a sufficient condition for the 
security property, and verify it by model checking. It would be worth examining 
how the semantics defined in this paper can be used to provide a formal proof 
of correctness of their analysis. 

6 Summary 

We have described a small-step operational semantics of a representative subset 
of byte codes pertaining to the Java Card firewall. In doing so, we have delib- 
erately abstracted away certain aspects of the language; for example, numeric 
calculations are not modelled. The continuation of this work is to demonstrate 
that the level of abstraction chosen is suitable for constructing and arguing the 
correctness of verification techniques for the firewall. 
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Abstract. We describe a successful implementation of a theorem prover 
for modal logic S4 that runs on a Java smart card with only 512 KBytes 
of RAM and 32KBytes of EEPROM. Since proof search in S4 can lead 
to infinite branches, this is “proof of principle” that non- trivial modal 
deduction is feasible even on current Java cards. We hope to use this 
prover as the basis of an on-board security manager for restricting the 
flow of “secrets” between multiple applets residing on the same card, 
although much work needs to be done to design the appropriate modal 
logics of “permission” and “obligations” . Such security concerns are the 
major impediments to the commercial deployment of multi-application 
smart cards. 

Keywords: security of mobile code, modal deduction 



1 Introduction 

Smart cards are credit-card sized pieces of plastic with an embedded silicon 
chip. Smart cards are either memory cards, which cannot be programmed, or 
microprocessor cards, which contain a small amount of RAM and disc (EEP- 
ROM) on the card itself. A card reader /writer is required to provide power to 
the card, to provide a clock signal, and to act as an interface between the card 
and the terminal (a PC, an ATM machine, a public telephone, or even a mobile 
telephone) . 

Java cards are smart cards that contain a (downsized) Java platform, installed 
by the manufacturer, thus allowing users to download Java applets and run 
them on the card. Java cards can therefore provide multiple applications such as 
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electronic purse, credit card, passport, loyalty programmes, all residing on the 
same card. 

The Java cards used in this project were the GemXpresso RAD Protyping 
card, containing a 32-bit microprocessor with 512 bytes of RAM, 32 KBytes of 
Flash EEPROM and 8 KBytes of ROM. 

Current Java cards are preprogrammed to contain applets by the manufac- 
turer for the card vendor, typically a bank (for credit and debit cards), or an 
airline (for frequent flyer cards). But if Java cards are to succeed then a card 
carrier must be able to down- load new applets onto an existing card “just in 
time” , or even merge existing cards into one card. This would mean that multi- 
ple applets from different vendors would reside on the same card. 

The single biggest problem with this scenario is that of security. How can we 
guarantee that a simple query to the drivers licence section of the card for iden- 
tification purposes (say) will not steal money from the card’s electronic purse? If 
new applets are to be down-loaded then how can the vendor of applet A ensure 
that a competing vendor’s applet will not be down-loaded at a later stage and 
steal information from applet A? Alternatively, applets A and B may trust each 
other to some extent, and therefore share some information. But if applets B 
and C enjoy a similar trust relationship, how can A be sure that B will not tell 
C information which it has obtained from A [Gir99,PB00] ? 

Many methodologies for guaranteeing such security have been investigated, 
but almost all of them involve a trusted “third” party. Eor example, the bank 
applet may be signed using a digital signature obtained from the government 
that certifies that the applet really did originate from the bank in question. The 
digital certificate is decoded by the card’s on-board digital signature chip and 
the applet is allowed to access the card’s electronic purse. But the need for a 
certification agency and a certification procedure makes this avenue cumbersome. 

An alternative methodology that involves no third parties is for card owners 
to implement a personal security policy using some international standard “lan- 
guage for security” . The electronic purse applet installed on the card may come 
with such a built in security policy which the user is prompted to tailor to his or 
her needs. Another applet which wishes to access the electronic purse must now 
pass a challenge determined by the level of security chosen by the card user. 

As new applets are added to the card, they are slotted into this set up either 
explicitly by the card user, or by some implicit default method. The simplest 
method is to use some form of access control list as is done by the Smart Card for 
Windows system (http: //www.microsoft . com. smart card), which uses simple 
propositional logic in its access control lists. A more sophisticated approach 
is to use a hierarchy with the “public” applets at the bottom, the “private” 
applets at the top, and the others in between these two extremes in some partial 
order [Gir99,PB00]. But this work does not address the problem of the dynamics 
of this partial order when a new applet is down-loaded. In particular, how can we 
be sure that all the previously checked “shared secrecy” conditions are satisfied 
by the new hierarchy ? 
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One way to define such a security policy is to use formal mathematical 
logic and to ensure that the permission granted to down-loaded applications 
meet certain rigorously defined security criteria expressed as formulae of logic. 
For example, notions like “agent i trusts agent j” are easily encoded as state- 
ments of multi-modal propositional logics, which are now well-established in 
artificial intelligence research as bases for defeasible reasoning [Shv90] , logics of 
agents [RG93], and logics of authentication [BAN90,Mat97]. Multi-modal log- 
ics like Propositional Dynamic Logic [Gol87] have also been used to model the 
changing states of a program. Finally, propositional bi- modal tense logics give a 
very simple and elegant model of the flow of time [HG96] . 

Ghecking that a down-loaded applet meets the security criteria is now reduced 
to proving, on-board, that an appropriate formula is a theorem of the logic used 
to code the criteria, since this is the only computer that the customer should 
trust. Multi-modal logics are particularly well-suited to this task as most of 
them are decidable. Consequently, the ability to perform automated multi-modal 
deduction on Java smart cards may be of use in electronic commerce. 

But surely multi-modal deduction is simply too difficult to perform on a 
smart card with extremely limited resources ? After all, even classical proposi- 
tional logic is NP-complete, and most multi-modal logics are actually PSPACE- 
complete! 

In [GNgOO] automated deduction in bi-modal tense logics was shown to be 
feasible on a Java smart card. It is reasonably straightforward to extend this work 
to other multi-modal logics, and hence to logics of knowledge and belief, or to 
logics of authentication and security. But many of these logics (e.g. PDL) contain 
operators which are inherently transitive, and transitivity can lead to infinite 
loops. Here we show that transitivity is not insurmountable by implementing a 
prover for modal logic S4. Thus our work is “proof of principle” that a logic-based 
security policy could be implemented on current Java cards. As the resources 
and speed of Java cards skyrocket, the task will only become simpler. 

The paper is set out as follows. Section 2 describes the logic S4 and the basics 
of modal theorem proving using tableaux. Section 3 explains the design of our 
prover CardS4. Section 6 presents test results and Section 7 presents conclusions. 

Acknowledgements: We are grateful to Didier Tolle of Gemplus Australia 
for donating the hardware necessary to carry out this project. 

2 Syntax, Semantics and Tableaux for Modal Logic S4 

2.1 Syntax and Semantics for S4 

Given a denumerably infinite set of atomic formulae PRP = {po,Pi,P2r ' ^ 

formulae p of modal logic is defined using the following BNF grammar: 

p::=Po\pi\p2\--- 

(p ::=T \ ±\p\ -'(fi I A (^2 I V (^2 I ^ (^2 I I 
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w p 
w A A B 

w A — > B 

w ^ OA 



for every w eW 
if re G R {p) 
if w A and w \= B 
if w ^ A OT w B 
if {3v G R{w)){v 1= A) 



re ^ T 

re 1= ^A if 
re 1= V -B if 



for no re G VP 
w ^ A 

re ^ A or re ^ B 



re 1= BA 



if (V-e G B(re))('e ^ A) 



Fig. 1. Kripke semantics for S4 



The standard Kripke semantics for S4 are as follows. A Kripke frame is a pair 
(VP, R) where VP is a non-empty set (of worlds) and B is a binary relation over VP. 
A Kripke model (VP, B, V) is a Kripke frame (VP, B) augmented with a valuation 
V : PRPU{T, T} 2^ mapping each atomic formula and atomic constant to the 
subset of VP where they take the value “true”. If re G V{p) we write w \\~ p and 
extend this satisfaction relation to arbitrary formulae in the usual way [HC96] 
as shown in Figure 1 where for any w G VP, B(re) := {-e G VP | wRv}. 

An S4- model is a Kripke model where B is both reflexive (Vre G VP)[reBre] 
and transitive (Vrei , rc 2 , res ^ VP)[reiBre 2 & W 2 Rws ^ reiBres]. 

A formula cp is S4-satisfiable if there exists some S4-model with some w G W 
such that w \\- ip. A formula (p is S4- valid if re I h V{(p) for every re G VP in every 
S4-model (W,R,V). 



2.2 Proof Search in S4 Using Tableau Calculi 

The problem of deciding whether or not a formula is S4-satisfiable is known to be 
PSPACE-complete [Lad77a,Lad77b] although the best known decision procedures 
use only 0(?r^./o^n)-space [Hud]. 

The most popular method for implementing theorem provers for S4 is to use 
the tableau method [Fit83,Gor99]. In addition to the standard rules for classical 
propositional logic, we require only the following two rules, and their duals for 
-iD and -lO obtained via the equivalences ^Bcp = O^cp and ^Ocp = n-i(^: 



(□S4) 



X,aif,ip 



(OS4) 



X, ay, Oif 



An S4-tableau for a finite set of formulae Z is a binary tree of nodes where: 
the root node contains Z and the children are obtained by an application of some 
tableau rules for S4 to the parent node. The rules are applied systematically so 
that the nS4 rule is applied only to a “saturated “ node: a node to which all 
other rules have already been applied. A branch of such an S4-tableau is closed 
if its leaf node contains both ip and ~^ip for some formula ip] otherwise the branch 
is open. The whole S4-tableau is closed if every branch in it is closed, otherwise 
it is open. 

Theorem 1 (Soundness and Completeness). The finite set {^ip} has a 
elosed S4-tableau iff the formula ip is S4-valid [Fit83,Gor99j. 
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Corollary 1. If every S4-tableau for the finite set is open then the formula 
ip is S4-satisfiable. 

The completeness proof gives a systematic method for proof-search which 
consists of repeatedly applying all the rules of classical propositional logic, and 
the (nS4)-rule, until no more applications of these rules is possible. The resulting 
node then corresponds to a “saturated” world in the underlying Kripke model 
under construction; see [Gor99] for details. Some O-formula is then singled out 
for attention from this “saturated” node and a “successor” is created for it using 
the (OS4)-rule. 

Naive proof search for a closed S4-tableau for some finite set of formulae Z 
using this systematic method can lead to infinite loops viz Z = {nOp,p}: 



nOp,p 
nOp, Op,p 
nOp,p 



(□S4) 

(OS4) 



One solution for detecting loops involves storing certain nodes as they are 
encountered, checking for repetitions, and backtracking if necessary. 



3 Algorithms 

We now describe our algorithm and data structures in more detail. 



3.1 Terms 

Negated Normal Form: Input formulae are assumed to be in negated normal 
form (NNF): all implications ip ^ (j) are rewritten as -i(pV(/), and negations are 
pushed through all connectives so the negation symbol appears only before 
atomic formulae. This requirement is not restrictive since every formulae can 
be converted into a logically equivalent NNF formula in linear time [BG98]. 
The advantage of using NNF is that the formulae in the parse tree of the 
NNF formula constitute all of the formulae that can appear in any node of 
the search tree. 

Parse tree: A formula is parsed as a tree, where each node has at most two 
children. The nodes are characterized as CONJ, DISJ, ALL, SOME if they are of 
type ipAfj, Dp, Oip respectively. At the leaves there are literals: atomic 

formulae or their negations. Each node represents a sub formula of the original 
NNF formula, with the root representing the whole NNF formula. With the 
tableaux rules above, it can be shown that the subformulae that appear in 
the parse tree are all the formulae that can appear in the nodes of the search 
tree. Clearly, the number of nodes in the parse tree is less than or equal to 
the length of the formula (it is exactly the length of the formula less the 
number of negative symbols). The number of formulae in any node of the 
search tree is therefore less than the length of the original NNF formula. 
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The parse tree is indexed so that each parent node has a smaller index than 
its children. This simplifies the visit sequence of the parse tree, as can be 
seen below. 

Search Tree: In the sequel we refer to the S4 tableau as the search tree. 
Model Tree: We refer to the underlying Kripke (tree-)model as the model tree. 

By “path” we mean an i?-path in this model tree. 

Good Nodes: A node of the search tree is “good” if no application of the OS4 
rule to this node gives a closed branch. 

no, nn, nv, ri/\: The number of subformulae of the appropriate type in the 
original NNF formula. 

3.2 Storing Nodes in the Search Tree 

The parse tree provides access to the finite list of all formulae that can appear in 
the nodes of the search tree. Thus each node in the search tree can be represented 
as a bit string, whose bits indicate whether or not the corresponding formulae is 
present in the node. This bit string has length equal to the length of the original 
formula. Thus storing one node in the search tree requires n bits, where n is the 
length of the original formula. 

3.3 Loop Checking 

As shown in Section 2.2, an S4-tableau can contain an infinite branch. This 
problem can be solved by noticing that only a finite number of different nodes 
can appear in a search tree, and by avoiding examining any node twice. Thus if 
a node has ever been encountered before, it can be safely ignored. 

The naive solution is to store each “saturated” node of the branch in a check 
list since these nodes correspond to worlds in the counter-model under construc- 
tion, and to explicitly look for repeated worlds. When a world re- appears, we 
must terminate proof search along this (open) branch and backtrack to the pre- 
vious application of the (OS4)-rule to choose a principal formula O^p different 
from the Oip that lead to this loop; see the (OS4)-rule. If all such choices lead 
to open (or looping) branches, then we backtrack higher up to the previous ap- 
plication of the (OS4)-rule, and so on until all avenues have been explored, or 
a closed S4-tableau is found. This, however, is not a practical method, since it 
would require exponential space to store all the possible nodes of the search tree. 

A better method is to check for repetitions of the nodes obtained by the 
application of the OS4 rule since these contain the “core” of the new world. 
That is, the OS4 rule is a transitional rule which goes from one world in the tree 
model to one of its successors. Thus the latter method looks for repetitions of 
the initial configuration of each newly generated world. This also guarantees the 
solution for the infinite branch problem, yet requires polynomial space. The price 
is that identical nodes on different branches now have to be treated separately. 
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3.4 A Straightforward Nondeterministic Algorithm 

The following algorithm returns true if a given formula ip^ of length n is S4- 
satisfiable, and false otherwise. It requires space. 

stack ::= empty 
check List ::= empty 
currentWorld ::= {(^ 0 } 

do 

while there are A, V, □ rules that can be applied do 
apply these rules to currentWorld 
if the rule applied is an V rule then 

push {check Li stSize^ left child of the rule) onto stack 
currentWorld ::= the right child of rule 
end if 
end while 

if currentWorld is inconsistent then 
if the stack is empty then 
return false 

else 

{check Li stSize^ currentWorld) ::= pop from stack 
resize checkList to checkListSize 

continue 
end if 
end if 

if currentWorld appears in checkList then 
return true 
end if 

if no (OS4)-rules can be applied then 
return true 
end if 

non-deterministically pick a formula <>p from currentWorld 
apply (OS4)-rule using <>p to currentWorld to get newWorld 
put currentWorld into checkList 
currentWorld ::= newW orld 
while stack is not empty 



Space Complexity It can be seen that stack grows by 1 only when the (V) 
rule is applied. Thus for one world, we may need to store the maximum of n^ 
possible configurations. Also the transitional rule (OS4) which moves from one 
world to another preserves all the n-formulae, thus the set of all n-formulae 
(the core) in consecutive worlds in a branch of the search tree do not decrease. 
Therefore there are at most nn different cores in the same branch of the search 
tree. Also the worlds that have the same core will form a chain in the branch. We 
need to find the maximum number of worlds in a chain that have the same core. 
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Since each new world is formed by taking all the □ formulae from the previous 
world together with one of the O formulae, the maximum number of worlds in 
the chain that have the same core is n<>. Altogether, the maximum number of 
configurations that we need to store in the stack is riv x rin x n<> < (a better 
approximation is n^/3). 

It can be seen that checkList contains only the node which is obtained by ap- 
plying a (OS4) rule. It is also resized so that all the nodes it contains are the ini- 
tial configurations of the worlds in the current search branch. Thus checkList is 
always smaller than or equal to stack. Overall, the maximum number of config- 
urations we might need to store in stack and checkList is of order . Given 
that a configuration needs n bits, the space complexity of this algorithm is 
[Lad77a,Lad77b]. 



3.5 An Improved Algorithm 

First, the non-determinism must be eliminated. Note that a node in the search 
tree is good if every node that is obtained from it by applying the (OS4) rule 
is good. Thus non-determinism can be eliminated by examining every node ob- 
tainable from a node by the (OS4) rule. This can be done by storing the world 
configuration before applying the (OS4) rule and keeping the index of the last 
(OS4) rule applied to that configuration. 

Second, it is not necessary to store all possible different configurations of a 
world since we can obtain some configurations from others. Notice that when 
applying an V rule, choosing a different child of the V formula gives a different 
possible configuration. Thus if each subformula of the original formula is named 
differently then it is possible to move from one node in the search tree to its 
sibling without storing them. This naming of the nodes of the parse tree for- 
bids common sub-expressions and therefore introduces some redundancy. There 
may be duplications of the same subformula, but they are named with different 
indices, so they must be examined independently. 

In the following algorithm, the stack stores only the configurations that have 
been fully expanded with non-(OS4) rules. 

checkList ::= empty 
stack ::= empty 

currentWorld ::= world consisting of the original formula 

do 

while there are A, nS4 rules that can be applied do 
apply these rules to currentWorld 

end while 

if there are V rules which can be applied then 
apply these rules to currentWorld such that 
if one child of the V formula is already in currentWorld then 
take that child into currentWorld 

else 

take the first child of the V-formula in to currentWorld 
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end if 
continue 
end if 

if currentWorld is inconsistent then 
mark currentWorld as closed 

end if 

if currentWorld is marked elosed then 

if there is another sibling of currentWorld then 
take currentWorld to be that sibling 

reset lastK Andex to indicate no OS4 rules have been applied yet 

continue 

else if the stack is empty then 
return false 

else 

(lastK Andex^ currentWorld) ::= pop from stack 

pop from checkList 

mark currentWorld as elosed 

continue 
end if 
end if 

if no more (OS4) rules can be applied then 
if stack is empty then 
return true 

else 

(lastKAndex^ currentWorld) ::= pop from stack 
pop from checkList 

end if 
end if 

lastK Andex ::= the next O-formula from currentWorld 
apply the OS4 rule to currentWorld to get newW orld 
if newW orld appears in checkList then 
continue 
end if 

put {lastK Andex, currentWorld) into stack 
put newW orld into checkList 
currentWorld ::= newW orld 

continue 

while stack is not empty 



Note that now checkList and stack are of the same size. The checkList is 
actually the core of the world configuration stored at the corresponding location 
in stack. Thus it can be obtained from stack by generating the core of each 
world in stack. This gives a more efficient use of space. It can be seen that for 
one node in the search tree, we need only one location in stack. Thus the space 
requirement is reduced by a factor of n^ : the maximum number of configurations 
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stored in stack at one time is rin x no < and the space complexity of this 
algorithm is n^ (a better approximation is nn x no < ^^/2, and the space 
requirement is n^/2). 

4 Data Structures 

4.1 The Parse Tree 

The parse tree is stored in two byte arrays, one (childs) of length 2n and the 
other (nature) of length n. The 2i and 2i + 1 entries in the first array indicate 
the children of the i-th node in the parse tree (i.e. the indices of some other 
nodes in the parse tree, or the atom at that node), while the i-th entry in the 
second array indicates if the i-th node in the parse tree is a □, O, V, A, -i or 
PRP. The V and A nodes have two children. The n, O, -i and PRP nodes have 
one child, thus the second child for these node is redundant. This is not a severe 
problem, since the parse tree is fixed through the proving procedure. Note that 
in case of the -■ and PRP nodes, the 2i entry of the child array contains the atom 
itself, not the index to another node in the parse tree. 



4.2 The Nodes in the Search Tree 

As discussed above, each node in the search tree can be represented as a bit 
string of length n. To examine all the (OS4)- rules that can be applied to a node 
(i.e all the O formulae in that node), we need to store the index to the last O 
formula that has been examined, requiring one more byte. 

4.3 The Stack 

Nodes are stored in a stack so that other branches in the search tree can be 
generated from the current branch, and so that a new node can be checked for 
duplication. This requires searching through all nodes in the stack, and also 
pushing and popping from the stack. 

There are several possible implementations for the stack. The first two options 
store the stack as an array of bytes, and do not need extra memory for pointers. 
Since multidimensional arrays are not supported, access to elements of the stack 
will require some extra computations. 

The upper bound of the size of the stack is known as seen above. Thus the 
stack can be allocated at the beginning of the procedure. We then need not 
worry about the growth of the stack. However, this is not a practical method, 
since the stack rarely grows to its theoretical upper bound size. Also, the limited 
amount of memory on the card will restrict the size of the input formulae. For 
example, with 512 bytes, the length of the formula will be less than 16 (16^/2 
bits = 512 byte). Allocating more than the card’s RAM is possible, however 
it involves swapping to and from the EEPROM and will slow down the proof 
procedure. Consequently, the card reader usually cannot wait for the card and 
will throw an Exception. 
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Another way to implement the stack is to pre-allocate a small stack, and 
gradually increase its size by a large step when it becomes full. This ensures 
that the memory is used more effectively. However it still contains redundancy 
since it allocates more space than required each time it becomes full. Thus the 
longer formulae will result in larger redundancy. It also involves a lot of copying 
each time the stack grows. 

The stack can also be implemented as a one way link list. Each node in the 
search tree is an element of the list. This requires extra memory for a pointer 
to the next element. However this extra memory becomes insignificant for long 
formulae. There is no redundancy. With this approach, the program has been 
tested for formulae of length up to 120. 

5 Implementation 

The program consists of two packages: card and client. The client package 
contains the classes for parsing the formula and converting it into NNF. Parsing 
is done by using Javacup (version l.Oj). We need a scanner (scanner . java) and 
a specification (parser . cup) for the formula, and Javacup automatically creates 
the parser. There is also a card proxy which manages the interactions with the 
card on behalf of the users. The class for testing is also in this package. Note 
that all of these operations are done off-board on a terminal (PC). 

The card package contains an interface and two classes that are down- 
loaded onto the card. These are classes prover and State, and the interface 
prover Interface The interface prover Interface provides access to the ser- 
vices offered by the prover. These include loading the formula onto the card and 
proving. The interface also defines constants that are used by the prover, and are 
also used in the parsing and converting procedures. The class prover contains 
the codes for the proving procedure. The prover object that is loaded onto the 
card reserves enough space to hold the longest formula. When the formula is 
put onto the card, it is stored in the object. The user then must explicitly call 
the prove procedures. The prove method reads the formula from the object, 
performs simplifications and then starts looking for a model for the formula. 
(Note that there is a separation between loading the formula and proving. This 
is due to the fact that loading is rather complicated, and it is discussed in the 
next paragraph). 

Despite the limitations of the card, the prover is able to work for a number of 
long formulae. Tests have been conducted for formulae of length up to 120. Pass- 
ing the input to the card and storing input in the card then requires greater care 
because communication with the card is not simple. There is an upper-bound 
for the amount of data that can be transfered in one transmission (approaching 
64K is not recommended) . Long formulae therefore need to be broken into small 
pieces. Here, the input arrays are split into pieces of length 32 bytes and each 
pieces is passed separately to the card, together with its length and position in 
the original array. Thus the maximum amount of data in one transmission is 34 
bytes (one byte for the length and one for the position). 
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Since the inputs to the prove method are not ready in one pass, they need to 
be stored in the object prover, requiring the reservation of space for the longest 
input. Note that this also implies more time is required for copying the input 
from EEPROM to RAM in the prove procedure. 

6 Results 

This section shows the average time spent on the card in proving randomly 
generated formulae of various lengths (from 20 to 120). As can be seen, the time 
increases with the length of the formulae since longer formulae generally require 
more stack space, and require more arithmetic operations in the calculations. 



time (ms) vs formulae length 
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Fig. 2. Time (ms) vs formulae length 




7 Conclusions and Further Work 

We have shown that even modal logic S4 can be handled on a Java card. Thus 
transitive modal logics are not necessarily beyond the scope of Java cards. We 
now need to invent appropriate logics of permissions and obligations to allow 
us to capture basic security notions like “trust”. This is the subject of further 
work. 

Another method for loop checking is to keep track of certain formula using 
a history mechanism [Heu99]. We intend to investigate whether such a history 
mechanism can be easily used in CardS4. 
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Abstract. With the growing number of smartcard applications there 
comes an increasing need to restrict access to the card itself. In previous 
work we proposed the pressure sequence biometric, within which a bio- 
metric sensor is integrated onto the card in a low-cost and mechanically 
compliant manner. Using an off-card verifier we demonstrated reason- 
able discrimination between users. In this paper we consider a number of 
on-card verification schemes, the best of which offers an equal error rate 
of 2.3%. On-card computational time requirements were found to be 3.1 
seconds for enrolment and 0.12 seconds for verification. Incorporating 
our implementation into an existing applet used 684 bytes of program 
space. Whilst data memory requirements are estimated to be 1400 and 
300 bytes for enrolment and verification, respectively. These time and 
size requirements demonstrate our biometric as a practical proposition 
for the protection of smart cards. Experiments were performed with the 
iButton ’s Java Card platform. 



1 Introduction 

In the rapidly growing world of the Internet and e- Commerce, smart cards of- 
fer the potential to protect data. This illustrates just one of the functions of a 
smartcard driving the motivation to protect and secure access to the smartcard 
itself. A number of schemes have been proposed whereby some device external 
to the smart card captures a biometric quantity, which is subsequently verified 
on a smartcard platform [19]. Off-card sensors suffer from the limitation that 
the external biometric device must be both present and trusted. This is hard to 
achieve [7]. In earlier work [8] we proposed the pressure sequence method, a novel 
biometric, which is both mechanically and economically compliant for incorpo- 
ration onto the smartcard itself. In this paper we report on the implementation 
of enrolment and verification functions of our biometric on Dallas Semiconduc- 
tor’s iButton Java Card platform [18], thereby demonstrating the viability of 
our biometric from the perspective of available computational resources. 
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The pressure sequence method measures the differences with which a user 
taps a sequence, or rhythm, upon a simple polymer pressure sensor. The recog- 
nition of people from a series of taps or pulses has some precedent. For example 
early telegraphic operators recognised other operators by the way in which they 
keyed information. Operators developed a distinctive ’fist’ or telegraphic style 
that could be recognised [4] . Indeed much work has been reported on the use of 
a person’s typing style, or keystroke dynamics [9], as a route to identity verifi- 
cation. Rumelhart and Norman [17] offer an explanation for the discriminating 
basis of keystroke dynamics, suggesting that differences in typing style are due 
to both the physical characteristics of the hand - such as finger length and agility 
- and the level of motor control of a person. 

The pressure sequence method seeks recognition by the pattern of pressure 
pulses between fingertip and pressure sensor, resulting to some measure from the 
biomechanical characteristics of a person’s hand and wrist. The human hand is 
complex and offers scope for discrimination between people. This is demonstrated 
in its composition of 19 bones, 19 joints and 20 muscles, combining to give 22 
degrees of freedom [11]. 

For the pressure sequence method to gain merit as a verifier, a high level of 
discrimination must be demonstrated. Since there are strong similarities between 
the pressure sequence method and that of keystroke dynamics, the discrimina- 
tion methods of keystroke dynamics have been investigated for their potential 
to discriminate between people, based only on a sequence of taps on a single 
pressure sensor. This is justified in that both result from similar neurophysio- 
logical and biomechanical mechanisms and that, at a minimum, both consider 
time intervals between finger taps. 

2 Experimental Method 

To validate the pressure sequence biometric, 34 students and staff from the Elec- 
tronics and Computer Science department in Southampton participated in an 
experiment. Each volunteer was asked to choose a short tapping sequence (typ- 
ically lasting between 2 and 4 seconds), and to tap that rhythm 30 times. Data 
collection from each volunteer was collected in one single session in a supervised 
manner at all times. For further details see our earlier work [8]. Figure 1 shows 
the analogue waveform of a pressure sequence. It is with these macro features; 
Pulse Heights, Pulse Widths and Interval Durations, that the pressure sequence 
method aims to discriminate between a valid and an invalid user. A feature ex- 
traction algorithm was devised to pre-process the analogue waveform, generating 
a single column feature vector comprising of (PulseHeight(l), PulseWidth(l), In- 

tervalDuration(l) , , IntervalDuration(n-l), PulseHeight(n), PulseWidth(n)), 

where n is the number of pulses in a sequence. Table (1) represents the sequence 
presented in figure 1 as a feature vector. 
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Fig. 1. Unprocessed Pressure Sequence 
Table 1. Corresponding Feature Vector 

























|1 


n 




lJ 






















































i_ 




1 1 1 


L _ 









Pulse 1 
Height 


Pulse 1 
Width 


Interval 1 
Duration 


Pulse2 

Height 


Pulse2 

Width 






Interval? 

Duration 


PulseS 

Height 


Pulse8 

Width 


52.13 


115.63 


215.5 


36.5 


105.38 






246.5 


48.25 


129.38 



3 System Architecture 

The pre-processing of raw pressure sequence data occurs within a separate bio- 
metrics module, comprising of analogue to digital conversion block, alongside 
feature extraction circuitry. We envisage this module being implemented in a 
small piece of silicon providing the interface between the analogue sensor and 
the smartcard’s processor. Figure 2 outlines this architecture. This implies that 
the smartcard’s processor will only be presented with the feature vector rep- 
resentation of the pressure sequence, and will not be required to monitor live 
real-time data. 
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Fig. 2. Biometric System Schematic 
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This paper assess the viability of using a standard processor for much of 
the hard work; future work will be to assess the integration of the electron- 
ics comprising the biometrics module; for example signal conditioning circuitry, 
analogue to digital conversion unit and how to protect the wiring on the card. 

4 Verification Schemes 

A number of authors have reported on the successful use of keystroke dynamics 
as a route to identification verification [20,14,2,10,1,3,13,16,12,6,21]. The process 
of verification is essentially the comparison of a live biometric sample to a stored 
reference template, calculated during the process of enrolment. If the live sample 
is sufficiently close to the stored reference, then the user’s identity will be con- 
sidered valid. If not, the user will be rejected and denied access to the services 
or facilities on offer. Due to the similarities, in terms of hand physiology and 
motor control, responsible for underlying mechanisms of both keystroke dynam- 
ics and the pressure sequence method, successful keystroke verification schemes 
have been assessed (in MatLab V5.3) for their success in recognising a pressure 
sequences. Table 2 shows our results. 



Table 2. Pressure Sequence Error Rates with Verification Scheme 



Verification Scheme 
Keystroke Dynamics Reference (s) 
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ii norm - Fixed Threshold [10] 
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£2 norm - Fixed Threshold [21,3,16] 


5 


41 


Component- Wise Linear [12] 
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MICD - Fixed Threshold [1] 
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Component- Wise non-Linear [12,16] 


3.7 
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ii norm - User Specific [10] 


2.3 
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£2 norm - User Specific 
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Mahalanobis - Fixed Threshold [16] 


3.4 
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Mahalanobis User Specific 


2.4 


10 


MICD - User Specific 


2.8 


11 



Figure 3 shows the effect of the acceptance tolerance on the false acceptance 
and false rejection rates, whilst figure 4 plots the false acceptance rate against 
the false rejection rate, or the Receiver Operating Curve (ROC), for the ii norm 
Method. This demonstrates the inverse relationship between False Acceptance 
Rates (FAR) and False Rejection Rates; as the acceptance threshold for a veri- 
fier is tightened, the number of false acceptances decreases. The penalty to pay 
is an increase in false rejections. This property allows the designer of a verifica- 
tion system the flexibility to match the verifier’s performance with the security 
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requirements of an application. The third column in table 2 shows the false re- 
jection penalties incurred in tightening the acceptance threshold to allow only 
1% false acceptances. 

Table 2 shows that the two best verification schemes; namely the user spe- 
cific ii norm and Mahalanobis Distance, demonstrate impressive discrimination 
properties. The next section deals with these verifiers in detail, outlining their 
implementation on the iButton. 




Acceptance Tolerance 




Fig. 3. FAR & FRR with Acceptance Fig. 4. ROC for LI Norm with User 
Tolerance Specific Threshold 



5 Implementing Verifiers on the Java-Enabled iButton 

A self-contained verification system embedded onto a smartcard must be capa- 
ble of performing both the enrolment and verification of a user in a reasonable 
time. We accept one-off enrolment times of a few seconds, and per-transaction 
verification times of less than one second. To test the suitability of our verifica- 
tion schemes, all 10 schemes above have been translated to Java and executed 
on a Dallas Semiconductor Java-Enabled iButton [18]. The iButton was cho- 
sen as a test-platform, being comparable to the latest generation Java-Powered 
smartcards, in terms of both processing and memory resources, whilst offer- 
ing accessible simulation and debug facilities. Applets were compiled using Sun 
Microsystem’s JDK2.1.1 under version 1.10 of Dallas Semiconductor’s iButton 
Development environment (iB-IDE). The resulting Java-Code was run on the 
JavaCard 2.0 compliant Java- Virtual-Machine (JVM) of the iButton. The enrol- 
ment and verification functions of each verifier were implemented in a skeletal 
applet, containing basic functionality to allow PC Host to iButton communica- 
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tion and the timing of enrolment and verification functions. The structure of our 
test applet is as follows: 

• Retrieve and store pre-processed enrolment vectors from PC 

• Record start time 

• Perform enrolment (a number of times) 

• Record finish time 

• Send total enrolment time and reference vector to PC 

Verification times were measured in the same way as enrolment times, with 
the verification function called in place of enrolment. Times were recorded using 
the iButton’s real time clock, which has a resolution of only 1 second. The ap- 
plet executes by firstly loading a user’s enrolment feature vectors, pre-processed 
from their enrolment sequences, to the iButton. The enrolment process is then 
repeated a number of times. Time is recorded using the iButton’s clock value, 
before and after a number of calls to the enrolment process. From these val- 
ues an average execution time is calculated. Total time required, along with the 
computed reference vector, is transmitted to the Host PC. Implementing the 
process in this way avoids lengthy PC to iButton communications which are not 
involved in the enrolment (or verification process) . This simulation assumes that 
the enrolment samples have already been captured, pre-processed, and are now 
available to the processor. Data capture and feature extraction pre-processing is 
the responsibility of the biometrics module, outlined in figure 2. 

5.1 Specific Implementation Issues 

There are two fundamental limitations to running our verifiers on the JavaCard 
platform; the restriction to 32-bit integers and hence the lack of floating-point 
data- types; and the lack of elementary mathematical functions, such as square- 
roots. 

The fixed threshold version of one of the most successful verification schemes, 
the ii norm is defined as: 



||M-T||i = ^|mi-t,| (1) 

i=l 

where M is the d dimensional reference- vector, generated from the mean of each 
of the components in the user’s enrolment vectors, T is a d dimensional test 
vector, and m and t are the components of M and T respectively. 

The identity of a user will be accepted if: 

||M-T||i<0 (2) 

where 0 is the acceptance threshold. 

Calculation of the ii norm is achievable with no loss of precision under the 
restriction of the 32-bit integer data type. Using a fixed acceptance threshold. 
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however, resulted in a rather uninspiring equal error rate (EER) of 9.7% (see 
Table 2), since the same acceptance threshold is used for all users irrespective 
of their natural variance. 

To improve upon this rate, the variation of a user’s enrolment vectors from 
their reference vector can be taken into account. This is performed in the manner 
of Joyce [10]. If each of the enrolment vectors are Si, S 2 , . . . , S^, respectively, 
then the norm between the reference vector, M and Sj is calculated for j = 1 to 
the number of enrolment vectors. The mean deviation D Enrolments and standard 
deviation, cf E nrolments of thcsc distances are calculated and used to decide an 
acceptance threshold on a per user basis. This results in acceptance of the user’s 
identity if: 

||h/[ T||i ^ \D Enrolment ' ^Enrolment\ (3) 

where r is the globally-set acceptance tolerance. 

The problem for the integer-only Java Card system is that calculation of 
(^Enrolments f^c Standard deviation of the distance between enrolment vectors 
and reference vector, requires calculation of a square root: 



(^Enrolment — 



/E"=i(S-M)2 



(n- 1) 



(4) 



Whilst the immediately obvious method for calculation of square roots, the 
Newton- Raphson method [15], is well known and used, it suffers from a number 
of problems. Eirstly, it is an iterative method, whose efficiency depends upon the 
quality of the initial guess. Secondly, applied to integers in its native form, the 
Newt on- Raphson method will infinitely oscillate between two integers, above and 
below a real non-integer root [5]. Crenshaw [5] has devised a simple algorithm 
for the calculation of square roots. His method is essentially a search through all 
possible integers until the integer part of a non-integer root is found. The sim- 
plest form of this is to search all possible integer square roots, x, for \fN until 
> N . The integer root of N is then the exit value of x, minus one. Crenshaw 
provides a more efficient implementation, arising from the observation: 

{x -h 1)^ = -h {2x -h 1) (5) 



This means that to check each new possible square root, (2x -h 1) merely has 
to be added to the previous square. The Java code implementation for this is 
presented as follows: 
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Java Code for Integer Square Root Funetion 

public static int SQRT(int a) { 



int square = 1 ; 


// 


x=l: 1st Integer Square Root 


int delta = 3; 


// 


(2x+l) , for x=l 


while (square<=a) { 


square+=delta ; 


// 


(x+l)''2 = x^2 + (2x+l) 


delta +=2; 


// 


Next value for (2x+l) 


j 

return (delta/2 - 1) ; 


// 

// 


square is now > a, so find 
previous value of x 



Although faster fixed cycle- length square root functions exist [5], the time 
required for execution of the enrolment process using this implementation was 
measured to be 3.1 seconds - well within the bounds of a reasonable duration. 
20 square roots were required for the enrolment process, each iterating 49 times. 
Verification required only 0.12 seconds for completion. 

Although the final values for the mean distance and its standard deviation 
between enrolment vectors and the user’s reference vector will be truncated to 
integer levels, the fractional loss is small relative to the distances involved and is 
not expected to cause any significant reduction in the verifier’s accuracy. Table 3, 
presenting the floating point and integer results from one user, illustrates this 
point. 



Table 3. Comparison of Floating Point and Integer Results 





Mean Distance 


Standard Deviation 


Floating Point Result 


221 


49.29 


iButton ’s Integer Result 


222 


48 



The second most discriminating method; the Mahalanobis distance verifier 
is defined as follows: 

(M - T) • • (M - T) < \D Enrolment ~ ' CF Enrolment] (6) 

where M, T, D Enrolment, T and cr Enrolment are as defined in (1) and (3), above. 

is defined as the inverse of a square dx d matrix whose leading diagonal is 
composed of the variances from each dimension of the enrolment vectors and all 
other elements are zero. 

This leads us to the problem that multi-dimensional arrays are not supported 
under Java Card 2.0, and as a result matrix manipulation will be both convoluted 
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and time consuming. The solution rests with the analytical reduction of the left- 
hand side of (6) to give: 



(M - T) • • (M - T) = ^ ^ (7) 

i=i 

where Vi is the variance of the component of the enrolment vectors. Equation (7) 
now offers a route to the direct computation of the Mahalanobis distance verifier. 
There is one further catch, however. Vi as the variance of each vector component, 
is the square of the standard deviation for that component. It is hence likely 
to be of comparable magnitude to that of the component values. The integer 
division, therefore, of {mi —U)‘^ hy Vi is extremely likely to result in the loss of a 
significant fractional part of the result, further compounded by the sum across 
all components. Pre-multiplying each numerator by \{)Re-quiredPrecision post- 
dividing the sum by the same enables retention of the fractional information. 
Table (4) provides the floating point, the integer and the pre- multiplied integer 
results. 



Table 4. Comparison of Floating Point, Integer and Pre-Multiplied Integer 
Results 





Mean Distance 


Standard Deviation 


Floating Point Result 


17.5 


5.56 


iButton’s Integer Result 


10 


4 


iButton’s Pre-Multiplied Integer Result 


17 


5 



Execution of the Mahalanobis enrolment process required 4.5 seconds, whilst 
verification required 0.16 seconds. 

5.2 Further Results 

The enrolment and verification times for the other verification schemes were also 
measured on the iButton. In addition the program size for enrolment and ver- 
ification functions, combined was recorded. Table (5) presents a comparison of 
these quantities, along with a repetition of the Equal Error Rates, for conve- 
nience. 

6 Conclusions 

The Java Card 2.0 platform does not support floating-point arithmetic. We show 
that 32-bit integer arithmetic offered by the iButton implementation of Java 
Card 2.0 is sufficient to implement on-card verification and enrolment for our 
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Table 5. Results for all Verifiers 



Verification Scheme 


Enrolment 

Time 

(Seconds) 


Verification 

Time 

(Seconds) 


Program 

Size 

(bytes) 


EER% 


ii norm - Fixed Threshold 


1.2 


0.12 


296 


9.7 


£2 norm - Fixed Threshold 


1.2 


0.26 


356 


5 


Component-Wise Linear 


1.2 


0.19 


285 


7.2 


MICD - Fixed Threshold 


1.2 


0.15 


319 


5.2 


Component-Wise Non-Linear 


2.9 


0.29 


524 


3.7 


ii norm - User Specific 


3.1 


0.12 


684 


2.3 


£2 norm - User Specific 


4.2 


0.25 


707 


3 


Mahalanobis - Fixed Threshold 


2.4 


0.16 


550 


3.4 


Mahalanobis User Specific 


4.5 


0.16 


752 


2.4 


MICD - User Specific 


8.5 


0.16 


704 


2.8 



pressure sequence biometric. We develop the necessary mathematics and esti- 
mate the errors introduced by representing real data as integer data. 

We measure the execution times and space requirements required by our 
implementation of verification and enrolment and show that they are within 
reach for a typical Java Card platform. 

We present an architecture for a complete on-card pressure sequence biomet- 
ric. In a previous paper we presented a method of integrating the physical sensor 
the plastic substrate of the smart card. In this paper we show that the process- 
ing capabilities required can be provided by a standard smart card. Future work 
includes an investigation into integrating the analogue electronics and the wiring 
on a standard smart card. 
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Abstract. Today mobile operators are in the possession of the SIM 
application toolkit technology available in their GSM SIM smartcards 
plugged into the mobile handsets of their subscribers. Although there 
are roughly 500 mio. SIMs deployed all over the world, they are not 
integrated into the Internet yet. With the WebSIM approach [6] we have 
demonstrated how SIMs can be integrated into the Internet by means 
of a tiny HTTP server implemented in a SIM to provide value-added 
services running on top of the SIM toolkit. 

In this contribution we propose to further extend this approach by mak- 
ing SIMs accessible as open and secure execution platforms for mobile 
code. Here, open means that virtually anybody in the Internet can use 
this mobile code platform, and secure means that both - platform and 
subscriber - cannot be harmed by malicious code. Such a platform can 
be provided by operators upon which third-party service providers can 
build their applications which would benefit from the security context of 
the smart card they run inside. 

The SIMspeak system is comprised of an off-card compiler, a verifier, 
and a corresponding card-resident interpreter, which can interpret code 
that has been pushed by an Internet service provider into a customer’s 
SIM. We describe the underlying trust model of SIMspeak, its architec- 
ture, language, and protocols. Furthermore we present approaches for 
end-to-end security that influence the design of the compiler, verifier, 
and interpreter and we give an overview on the current status of our 
implementation . 



1 Motivation 

Imagine you were participating in an on-line auction with eBay.com and you 
were bidding for an antique watch. After registering and placing a bid with 
your favourite browser, you fill in eBay’s form asking whether you are SIMspeak 
equipped. After entering the phone number of your SIMspeak-enabled SIM, you 
tell eBay to continue to push subsequent information and communication to your 
SIM. Until the end of the bidding phase you receive SMS messages at regular 
intervals from eBay containing small SIMspeak scripts that are interpreted on- 
the-fly upon arrival in your SIM. These scripts inform you about the current 
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highest bid in the auction, asking whether you want to place a new bid, enable 
you to enter a new bid and return the new digitally signed bid to eBay via SMS. 
Since you were equipped with SIMspeak, you were able to place a final bid just 
two minutes before the end of the auction while sitting in a train, and you are 
now a proud owner of the antique Rolex you dreamed of since the early days of 
GSM. . . 

Lessons learned from the WebSIM approach. The core idea behind our 
motivation is that a GSM SIM [4] is an ideal platform for communicating with 
mobile subscribers from the Internet in a secure push-based style of communi- 
cation as motivated above. We have already demonstrated with the WebSIM [6] 
how to integrate GSM SIMs into the Internet by an appropriate proxy architec- 
ture. There, each SIM has its unique URL to which HTTP requests can be sent 
containing SIM application toolkit commands (SAT) [3] that allow for user in- 
teraction. The proxy forwards the requests embedded into short messages (SMS) 
to the SIM. The requests are interpreted by a small Web server in the SIM trig- 
gering the SIM toolkit commands specified in the URL. The responses of, e.g. a 
SAT Selectitem command, are returned to the originator of the request. 

Basically, the WebSIM brings the GSM security infrastructure into the 
Internet upon which various protocols can be implemented, e.g. for au- 
thentication of Internet users via their mobile phones (cf. [9]). 

Unfortunately, the WebSIM does not allow for interaction as presented above in 
the mobile auction scenario for two reasons: 

— It lacks the possibility of launching more than one SIM application toolkit 
command at a time, thus it is not possible to encode some kind of user 
interaction in a request, and 

— it does not offer any end-to-end security between a service provider and the 

SIM. 

Our approach overcomes these drawbacks by opening the SIM in a flexible 
though secure manner for third-party application providers, mobile operators, 
and subscribers. We think that it should be possible for virtually anybody in the 
Internet with basic knowledge of Internet technology to develop SIMspeak ap- 
plications called scripts and send them via an operator’s gateway to the mobile 
subscriber’s SIM. The key approach is to send mobile code and data to a SIM for 
instant execution. Furthermore we are interested in confidential transmission of 
such scripts from the service provider to the SIM avoiding content-recoding prob- 
lems as known from the Wireless Application Protocol (WAP) or the WebSIM 
which leads to a breach of end-to-end security. 

Comparison with Related Work. The WebSIM and the SIMspeak systems 
share some similarity with several other technologies. 

WAP Push [15] defines the architecture underlying the future push-based 
technology in the WAP protocol family. Gontent is pushed via an appropriate 
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gateway architecture to a WAP-enabled terminal, hence it is targeted towards 
the mobile handset in contrast to the SIM. 

SIM toolkit browsers [12,13] provide a browsing technology on top of the 
SIM application toolkit. Applications are driven by a gateway usually hosted 
by a mobile operator. It also offers some means for end-to-end encryption of 
confidential data between the service provider and the SIM. In contrast, SIM- 
speak less addresses a browsing-like type of interaction initiated by the user but 
a push-based style of communication driven by an Internet client also aiming at 
true end-to-end security of transmitted scripts. 

The draft specification of the 3GPP USAT interpreter working group [1] 
comes the most close to our envisioned platform. This group defines the USAT 
interpreter that makes use of the SIM toolkit commands available in the future 
USIM. It does not only define a browser-based model but also allows for push- 
style communication from the gateway, which in turn can be triggered from 
the Internet. The byte-codes used there reflect the group’s idea of a pa^e-based 
style of subscriber interaction similar to the SIM toolkit browsers. As such they 
support pages as the elementary containers that can be linked by a web of 
anchors for navigation. Within a page, variables can be used to store page-local 
information and exchange data between different pages. Contained in a page are 
USAT commands encoded as tag- length- value data (TLV) structures providing 
a generic approach to subscriber and handset interaction. 

Although USAT interpreter and SIMspeak target similar application do- 
mains the actual approaches differ substantially: The SIMspeak platform is pro- 
grammable in terms of control-flow, arithmetics. Boolean expressions, response 
message formats, etc. The USAT interpreter, though, follows a more operator- 
centric model that has similar drawbacks as the SIM toolkit browsers w.r.t. end- 
to-end security, an issue further discussed in Section 4. Generally, a browser- 
based style of communication is suitable for many applications but the ability 
to perform local computations as envisioned in SIMspeak is of equal importance 
and not supported in the USAT interpreter model. 

The rest of this paper is organised as follows: In Section 2 we analyse the essential 
requirements of the envisioned platform. Section 3 describes the overall SIMspeak 
architecture, its language, and investigates the core components compiler and 
interpreter. Issues around end-to-end security are described in Section 4. Sec- 
tion 5 describes a sample script and illustrates a number of possible application 
domains and Section 6 discusses future work and draws final conclusions. 

2 Requirements Analysis 

The mobile auction example has motivated the need for an open and secure 
means to download mobile code and data into a GSM SIM for instant interpre- 
tation. In the sequel we discuss general requirements that should be guaranteed 
by the involved components and underlying protocols. 
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Roles and Trust Model. The envisioned trust model needs to support at least 
the following roles: 

— Subscriber or user is the owner of the mobile phone and target of all input 
and output facilities offered by the platform. 

— Service providers interact with subscribers by means of applications that 
are dynamically loaded into the provider’s platform. 

— Platform provider is the role that manages and controls the platform that 
provides means for interaction between service providers and subscribers. It 
should be noted that there is no general assumption that the SIM issuer also 
plays the role of the platform provider. 

In the traditional GSM world the SIM is basically trusted by (the mobile) oper- 
ator which means, that the mobile operator decides which applications to load 
onto the SIM. This mostly occurs at the time of card personalisation, sometimes 
afterwards. 

We argue that the SIM can be opened up for third-party service providers 
while preserving integrity and security of the SIM. This can be achieved by a 
platform operator who offers an execution platform inside the SIM that service 
providers can use to run applications that interact with subscribers. Therefore, 
the trust model must be extended in a way that both - service providers and 
mobile subscribers - trust the provider’s runtime platform in the SIM. Further- 
more, the operator does in general not trust the mobile code sent to the platform 
for execution. This problem is comparable to some extent with the issues around 
host seeurity in mobile code systems (cf. [5]) and the problem of security of mo- 
bile agents where a mobile agent distrusts the platform it is running on (cf. [14]) 
and we will apply common solutions known from this community. 

Platfrom Security Properties. We approach the problem by designing a 
platform such that all necessary security properties are decidable without human 
intervention, i.e. non-interactively. In the rest of this paper we discuss technical 
approaches to yield such a trustworthy platform without, however, giving formal 
proofs. We have identified the following security-relevant properties: 

— Application Provider Authentication: For a mobile subscriber it is of 
vital importance to identify the provider of the application running in her 
SIM. For example, consider the case of a script masquerading as a banking 
application that asks the subscriber for a personal identification and trans- 
action number, and subsequently uses this “stolen” information to issue a 
malicious transaction on the subscriber’s behalf. Therefore, the platform 
must offer suitable facilities to make the subscriber aware of the identity of 
the sender. 

— Code and Data Confidentiality and Integrity: Obviously, the trans- 

port of the mobile application comprised of the actual program and its data 
must be protected. Integrity of the shipped data is needed under all circum- 
stances. Whether confidentiality of the program, its data, or both is needed, 
depends on the particular application, and appropriate means to implement 
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a required level of security should be offered to applications. Hence, a flexible 
management of symmetric and asymmetric keys is mandatory. 

— Code Verification: Besides the integrity of the shipped program it must 
be guaranteed that malicious code does not compromise the platform’s secu- 
rity. Basically, well-formedness according to certain security properties can 
be checked in the card prior or parallel to execution, or off-line in some kind 
of trusted verifier. Typical properties include: 

• Syntactic integrity of the program. 

• Stack behaviour to avoid over- and underflow of the runtime stack. 

• Data typing to avoid type errors in the language’s type system. 

• Guaranteed termination of an application. Since smartcards cannot 
be interrupted during execution except resetting them, the platform is 
responsible for not allowing applications to run forever. 

Ideally, all of the above properties should be verified in advance to avoid 
cancelling an application upon a property violation at runtime. 

— Non-Repudiation: For the application provider it is of vital importance 
to have a proof on the inputs performed by a subscriber, e.g. entering the 
amount of money for the new bid the subscriber places in the on-line auction. 
This evidence must be created by the runtime platform, e.g. in the form of 
an electronic signature (cf. [2]). 

The previous list is by no means exhaustive and more requirements such as 
persistent storage^ transaetions^ etc. could optionally be considered. 

3 Architecture and Implementation 

The requirements presented in the previous section have shaped the approach 
taken in our architecture and implementation. 

Components. The overall SIM- 
speak architecture is depicted in 
Figure 1. Basic components are an 
Internet node, e.g. a Web server, 
to which SIMspeak scripts can be 
uploaded by means of HTTP(S) 
from any node in the Internet. 

This Web server acts as a gate- 
way from the Internet into the 
GSM world. Script pushing can 
be made subject to extensive ac- 
cess control, e.g. disabling access 
for any parties not authenticated. 

Furthermore the gateway can be Fig. 1. SIMspeak architecture 

used as a starting point for any 
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kind of billing mechanism implemented by the platform operator.^ This archi- 
tecture is directly derived from the one described in [6]. 

The SIMspeak compiler parses the uploaded script and checks for a number 
of security properties described later. Afterwards the byte-code for the SIM- 
resident interpreter is generated and packaged into a number of short messages 
(SMS) sent to the target SIM. 

Upon arrival in the SIM the interpreter collects the SMS until the script is 
complete. Then script execution starts and the script’s instructions are subse- 
quently interpreted. Possible responses from the SIM to the gateway are sent 
back to the gateway which can be delivered via an asynchronous or synchronous 
communication style back to the original sender, e.g. the response can be sent 
as the HTTP response of the initial script submission or by an appropriate no- 
tification mechanism. 

Language. A suitable domain-specific language for interpretation in a GSM 
SIM must at least offer primitives for control flow, data processing, and access 
to the SIM toolkit. We have chosen a stack-based interpretable programming 
language in the spirit of Forth [7] from which we have borrowed the stack model. 
Control structures and arithmetic operations have been added, and additional 
support for registers and bindings for SIM toolkit commands are available. The 
instruction set can be classified as follows: 

— Stack: pop, dup, swap, and push 

— Registers: load, store 

— Control-flow: nop, exit, if. . . goto, goto, call, return 

— Boolean: and?, or?, not?, eq?, le?, etc. 

— Arithmetics: add, sub, mul, div, mod 

— Cryptography: encode, decode, sign, digest, verify 

— SIM application toolkit: sat. select, sat. display, sat. input, sat. loci, etc. 

Data types. The following data types are supported: 

— Integers: At the moment the language supports only 8-bit arithmetics 
which should be extended to at least 32/64-bit for monetary applications. 

— Strings: We only support 8-bit strings for displaying and entering data 
which could be extended to 7-bit GSM and ISO-UCS2 encodings. 

— Boolean: Used for Boolean expressions and flow control. 

— Mark and Null: Used for stack element marking and a bottom type. 
Components and Implementation. 

— Gateway and Compiler: The gateway is responsible for the compilation 
of submitted scripts into a format understandable by the SIM-resident in- 
terpreter. Since resources on a smartcard in terms of processing power and 
memory are limited, the code generation should make it as easy as possible 
for the interpreter to actually perform the interpretation. 

^ Naturally, this conflicts with the idea of an open application platform but we consider 
such business issues beyond the scope of this paper. 
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— Interpreter and Verifier: The byte-code instruction set has been designed 
to obtain a very efficient encoding of scripts - both for small number of SMS 
and for easy interpretation in the SIM. We have tried to eliminate most 
data movements within the implementation to get reasonable performance 
and avoid the problem of memory management on top of the Java Card 
runtime environment. 

— User Interface Aspects: Since the platform controls any user interaction 
this “direct” link to the subscriber can be used for several purposes: 

• Script starting: Before a script actually starts, the subscriber can be 
notified, e.g. by playing a tone and displaying some information that 
a script has been received for execution. The platform can furthermore 
display the originator of the script and the user can accept the script’s 
execution, postpone it to later, or completely reject. 

• Location information: Access to location information can be given 
only after the user has explicitly accepted. Hence, a suitable menu can 
be displayed, querying the subscriber, whether the information may be 
given to the script, or not. 

• Response: Before a script sends responses back to the gateway, the 
subscriber can be asked to first authorise this process. 

— Implementation: The interpreter consists of about 1.500 lines of Java Card 
code compiling to roughly 15kBytes of class files. The SIMspeak applet size 
is about 4,4kBytes. The interpreter was built on top of Bull’s SIM Rock 
Java Card Toolkit based on the Java Card 2.1 API. 

The compiler is written in Java 2 and consists of about 4.200 lines of code 
including documentation of which approximately 50% are devoted to the 
script parsing code generated with the JavaCC parser generator^. 

After compilation the compiler yields a set of script segments ready for 
transmission to the SIM in any order. Each segment contains a header that 
identifies the current session and segment number to manage the arrival of 
SMS in a different order. A script is executed after all segments have arrived 
in the SIM. The gateway is based on the version implemented in [6] with 
extensions for sending more than one SMS. 

This architecture still suffers from the problem of end-to-end seeurity since the 
compiler at the gateway performs a translation of the submitted code. In the 
next section we elaborate concepts to overcome this drawback. 

4 Towards End-to-End Security 

Although in the previous paragraphs we implicitly assumed that the compiler 
and verifier are placed at the operator’s gateway, they can also be placed at 
different locations as Table 2 illustrates: 



^ Available at www.metamata.com/javacc/. 
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Platform 
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If the compiler is placed with the service 
provider, the operator ( 1 ) or the platform it- 
self (2) must host the verifier. Another option 
is to place compiler and verifier at the opera- 
tor (3). Furthermore the verifier can be imple- 
mented on the platform (4). Options (2), (4), 
and (5) are of particular interest since they 
aim at an on-card code verification. Option 
(2) is the most appealing since it opens up for 
end-to-end encryption of the whole application - program and data - not only 
data as in (4). Therefore, we have decided to approach end-to-end security using 
option (2) and aim at an on-card verifier implementation. 



Fig. 2. Compiler 
placement 



and verifier 



4.1 Compiler 

A compiler translates an input language into a compiled form intended for di- 
rect execution on a target processor or for interpretation. Within SIMspeak the 
compiler essentially aims at two major goals: (a) generate a compact encoding 
of scripts for bandwidth-saving over-the-air transmission, and (b) simplify the 
implementation of the on-card interpreter as much as possible in terms of code- 
size and execution speed, e.g. completely remove resource-intensive parsing of 
the input language. Following option (2) the compiler can be hosted and run by 
the service provider in addition to the gateway host (4). 



4.2 Verifier 

The verifier checks whether the generated code satisfies certain properties. The 
most common example of such a component is the Java byte-code verifier [11]. 
The verifier has to check for at least the following properties: 

— Syntactic integrity: Syntactic integrity of the byte-code is easy to check 
in advance as long as the representation is simple enough. 

— Data stack behaviour: The data stack is used for temporary storage of 
data and parameter passing to SIM toolkit library calls. It can be statically 
checked whether at any point of execution a stack violation occurs. 

— Data typing: At the moment we support only strings and integers as data 
types. 

Our approach is essentially a simplified version of the Java byte-code verification 
since, for example, we do not support user-defined types and exceptions which 
introduce an additional overhead for on-card verification (cf. [10]). 

Verification of Control-flow and Termination. One of the most problem- 
atic issues w.r.t. security is the fact that scripts running in the SIM always must 
terminate and that they are interruptible at any point of execution. Control-flow 
primitives are available through the if. . . goto statements and the primitives call, 
and return manipulating the control stack. We place the following restrictions 
on the control- flow graph of a script: 
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i. Subroutines can only be called. No goto from outside a subroutine to a label 
inside a subroutine is allowed. This yields closed subroutines. 

ii. Each path of execution within a subroutine must pass a return or exit state- 
ment to ensure proper termination. 

iii. The subroutine call-graph must be acyclic to avoid simple and mutual re- 
cursion. 

iv. The control- flow graph of the application or a subroutine may have cycles, 
iff along each cycle there exists a call to an interruptible interaction prim- 
itive. Currently, those are the SIM toolkit primitives display, select, and 
input. This ensures that an application or subroutine cannot loop without 
subscriber’s notice, thus a user is able to interrupt execution. 

Figure 3 illustrates the last property. It shows an example of a legal jump (in- 
dicated by an arrow) in the control- flow graph. Numbers indicate maximum 
distance to end of application (bottom- most node). Jump of interest is from 
node c to node n and is allowed since all possible paths from n to c pass a user 
interaction. 

These restrictions yield a very constrained 
domain-specific language that does not allow for, 
e.g. iteration over a fixed set of numbers without 
subscriber interaction. Furthermore, there is no 
support for dynamic data structures such as sets 
or lists. Despite these limitations we have found 
the resulting language very flexible for our ap- 
plication domain and we are still looking for in- 
teresting examples that cannot be encoded with 
the current set of language primitives and con- 
trol flow restrictions which would need further 
support from the platform. 

About Java Card. Very naturally the question arises ^'Why not use Java 
Card [8] applets for this purpose?""^ 

First of all we wanted to demonstrate the feasibility of our approach by start- 
ing top-down^ i.e. to explore, what is the minimal language needed to do useful 
things and how much in terms of on-card resources do we need to implement 
this functionality? Furthermore we were interested in performing a complete 
implementation with all the necessary functionality on-card. 

The object-orientation of Java is not a mandatory requirement for the in- 
tended application domain and just adds complexity without yielding concrete 
benefits. Furthermore, some properties, e.g. termination, require knowledge of 
the semantics of operations and library calls currently not inherently subject to 
Java byte-code verification. 

SIMspeak on the other hand follows a minimal approach that simplifies check- 
ing of properties in most cases but introduces further checks needed for its open 
platform approach. Our first results indicate that the verification of the termi- 
nation alone is rather complex to implement efficiently. 




Fig. 3. Control flow example 
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Summing up, we consider Java Card to be a very flexible platform and language 
for card-resident applications. In contrast, SIMspeak is meant as a domain- 
specific language targeting towards simple and short applications transmitted 
over-the-air that not only require special transport and loading protocols, but 
also have a different life-cycle which does not necessarily fit with Java Card. 
However, this does not imply that Java Card could not be a suitable language 
for implementing our approach in the future especially, if we consider recent work 
by Leroy [10] who reports promising progress in on-card verification techniques 
for Java Card byte- code. 



4.3 End-to-End Security Protocols and Key Management 

To support the above end-to-end approach, suitable communication protocols 
are needed. We propose to use public-key cryptography to enable secure end-to- 
end communication between a service provider and the platform as follows: 

— Public-key pair: Each card C owns a platform key pair {Sc^Pc)- The 
secret key can be installed in the platform at time of issuance by operator M, 
or later by on-card key generation.^ In the latter case a subscriber can trigger 
the key generation and the mobile operator can use the GSM authentication 
algorithm in combination with the SIM’s secret key Ki^ its IMS I identity 
number, and a nonce n to securely obtain the public key Pc from the card 
and at the same time verify its authenticity as follows: 

C : sig{IMSI,Pc,n}K^. 

— Trust center: The platform operator makes the public keys of the SIMs 
available as certificates in a central directory, e.g. Web or LDAP server. 
Hence, the directory provides a mapping P ^ Pc from a phone number P 
to the platform’s public key 

— Secret key installation: The platform offers each service provider S mech- 
anisms to install a secret symmetric key Ks into the platform. Each provider 
generates a unique key for each individual platform. This results not only in 
end-to-end confidentiality but also provides for authentication. Key installa- 
tion requires that the service provider authenticates first with the operator, 
e.g. using a PKI. The following protocol achieves this goal:^ 

S ^ M : {P, enc{Ks,i,k,n}pc}, 

M : D = sig{enc{Ks,i,k,n}pc,ids,m}Ki, 

M C : [^enc{Ks^ i, fc, n}p(^, Z)}. 

^ Several SIM smartcard manufacturers are planning to integrate RSA key generation 
into future products. 

^ If platform and mobile operators are different authorities, appropriate agreements 
must be established. 

^ Here again, n and m are nonces. 
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First the service provider sends to the operator the phone number P of the 
target SIM, the secret key Ks along with a sequence number i for replay 
prevention, a key store number k, and a nonce n, encrypted with Pc. The 
operator completes the message with the identity ids of the service provider 
and a nonce m, and signs it appropriately with Ki The message and its 
signature are then sent to the platform and after signature verification, Ks 
can be safely stored into the service provider’s key store at position k. 

— Secure end-to-end communication: 

Upon successful installation of the service provider’s key Ksj secure com- 
munication can be achieved as follows: 

• S ^ C : {ids, enc{prog,i,n}Ks^k}i 

i.e. S encrypts its data with Ks and annotates its identity ids for correct 
decoding. The platform decrypts the message with the secret key Ks 
stored as key number k from the sender’s key store. This step not only 
decrypts the message but also achieves achieves provider authentication 
which has been identified as a major requirement for the platform. 

• C ^ S : {IMSI,enc{E}Ks.k}, 

i.e. data E is simply encrypted with Ks. The IMS I (or another suitable 
identifier for the platform) and k are used to look up the appropriate 
key for decryption. Encryption can be achieved with the interpreter op- 
eration encrypt that performs encryption of the topmost stack element 
with a key from the key store. Since Ks is only known to the card and 
the service provider, it also achieves authentication of the card.^ 

In the above protocols we have not made concrete assumptions about the un- 
derlying public- and symmetric-key protocols. For usage in a GSM SIM, data 
blocks should generally be as small as possible which could give Elliptic Curve 
Cryptography (ECC) an advantage over, e.g. RSA. On the other hand we do 
not know of any ECC-capable GSM SIM at the moment. 

The protocols above also assume that the operator or platform provider has 
no means to access the service provider’s secret keys Ks or the secret key Sc 
of the card. Otherwise, the whole chain of trust would be compromised. Fur- 
thermore it is not explicitly stated that operator and platform provider must 
be the same body, e.g. the platform could be a separate application in a multi- 
application card offered by another third-party. If not, the operator might be 
responsible for the key pair generation and trust center responsibilities only, 
into which the platform provider must have sufficient confidence. 

Non-Repudiation. As outlined in the requirements analysis, assurance of non- 
repudiation is necessary for business-critical services and applications. We follow 
a straightforward approach by offering service providers the primitive sign that 
first displays a note that some data has to be digitally signed, then displays the 
actual data, e.g. and finally signs the cryptographic hash of the data h{D) 
with the subscriber’s signature key Ss which can be configured similar to the 



E may contain additional information, e.g. to prevent replay attacks. 
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platform key Sc- The digital signature obtained is pushed back onto the stack 
and can be subsequently sent to the service provider. 

4.4 Status of Implementation 

We have implemented an off-card verifier which is currently being ported onto 
a Java Card 2.1 SIM. We still experiment with different algorithms and encod- 
ings to obtain an efficient on-card implementation. In particular our approach 
is based on a scheme comparable to a simplified version of the Java byte-code 
verification focusing on byte-code encodings that allow for linear scanning of the 
whole application that are cheaply implementable on-card while leaving compu- 
tationally expensive operations to the off-card compiler. 

5 Sample Applications 

The Mobile Auction Example. The implementation of the illustrative eBay 
auction client example described in Section 1 is shown in Figure 4. 

A script starts with header information about the name of the script and its 
provider. The implementation part contains the actual program. 

Lines 14-16 demonstrate how to display an initial message about the latest 
news of the online auction. Lines 18-22 show how the arguments for a SAT Se- 
lectltem are pushed onto the stack marked by the initial marker set in line 18. 
After the selection has been performed the arguments including mark are re- 
moved from the stack and the number of the selected item is available on the 
stack. 

Lines 24-26 check, whether the subscriber selected the second item in which 
case a jump to the label at the end is performed. Otherwise an input dialogue is 
opened in lines 28-29 and the input from the subscriber is returned on the top- 
most stack position. Then a mark is pushed and swapped with the subscriber’s 
response in lines 30-31. 

Finally a return token is pushed onto the stack and the response containing 
all elements up to the mark are returned to the gateway. Depending on the kind 
of response - synchronous or asynchronous - the data is returned to eBay. 

The script compiles to exactly 198 bytes of which 156 bytes (80%) are text 
strings. This indicates that the chosen byte-code is very compact in relation 
to the overall data that needs to be transported anyhow. The codes fits into 
two segments (payload size of 112 bytes) that can be transported in two short 
messages. 

Further Application Domains. SIMspeak allows platform operators to offer 
of an open and secure platform to Internet service providers such as shops, banks, 
etc. It offers secure interaction of these providers with their customers in a push- 
based style of communication. To some extent one can view SIMspeak as a secure 
interpreter running in a smartcard inserted into the wireless card reader {mobile 
phone) that happens to be equipped with a keyboard and a display. The content 
pushed is not only data - as it would be the case for a hard-wired application 
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simspeak script { 



scriptname "ebayuauctioriuclient" ; 
provider "ebay.com''; 

implementation { 
sat.playtone; 

push("Newsjfroiiijebay.com:\nBiduinLjauctionu#3576u(Antiqueuwatch) :u$63. ") ; 
sat. display; 



push (mark) ; 

push ( ' 'PlaceLjnewubid? " ) ; 
pushC'Newubid. . . ") ; 
push ("Cancel") ; 
sat. select; 

push( 2 ) ; 
eq?; 

if (true) goto end; 

push ( ' 'Ent erLjnewubidu ( >$64) 
sat. input; 
push (mark) ; 
swapO ; 

push ("ebay, com: ul23456") ; 
sat. response 0 ; 



end: 

exit; 

} 

} 



// Mark following entries on stack 
// This is the title of the menu 
// First item 
// Second item 

// Pushes number of selected item onto stack 

// Number of choice of interest 
// Check for selected item == #2 
// Branch to end if selected "Cancel" 

"); 

// pushes entered value onto stack 

// Unique identifier for response 

// Send input on stack back to ebay. Stack 

// contents are identifier and newly entered bid 



Fig. 4. Listing of the SIMspeak implementation of the eBay example from Sect. 1 



in the SIM - but rather code and data, which makes it much more flexible. The 
following examples should give an impression on the types of applications that 
could be thought of: 

— Push-based brokerage, stock trading: A broker application is similar 
to the auction client. The subscriber could be informed about new stock 
watch-points that could be used in addition to stop- loss. It could provide 
more subscriber feedback to what is going on at the stock market and provide 
means to react on current trends in a matter of seconds. 

— Internet-based authentication: Possibly one of the most interesting class 
of applications is authentication of mobile subscribers to the Internet. Cur- 
rently, Internet servers accessed by HTTPS/SSL authenticate themselves via 
certificates whereas in practice client authentication is not used due to the 
lack of a global PKI infrastructure. SIMspeak can be used to implement 
various protocols how a service provider can send a script executing, e.g. a 
menu selection, whether the intended transaction or order should actually 
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be performed, or not. Further protocols and approaches are described in [6] 
and [9]. 

— Secure enterprise applications: Enterprises with a strong demand for 
secure and application-specific mobile transactions are likely to invest into 
customisable solutions. Especially flexible mechanisms for end-to-end secure 
communication between an enterprise and its mobile employees could be of 
particular importance. 

— Loyalty-points application: Smartcards offer secure persistent storage 
that could be used by loyalty point systems that manage the bonus points 
via GSM. This would provide a complete off-line light-weight loyalty system 
that uses the distributed secure storage of SIMs for management. 

Summing up, the SIMspeak architecture provides an open and secure platform 
upon which various other applications can be built on top of. 

6 Conclusions and Future Work 

The SIM is the security module of the largest security infrastructure the world 
has seen so far. The experiences gained from the Web SIM project have shown 
that the idea of integrating a GSM SIM into the Internet with suitable protocols 
such as HTTP can enable more secure business between subscribers and service 
providers. 

In the SIMspeak approach we have tried to overcome some of the existing 
limitations in the WebSIM approach by designing an open application platform 
inside the SIM that providers can use for implementing their own services. We 
have extended the Web server in the SIM by a platform for the execution of 
mobile code in a secure and safe way - from the provider’s, subscriber’s, and 
platform’s point of view. This platform allows a service provider to implement 
its own policies for security-sensitive transactions, e.g. in the fields of mobile 
commerce or business-to-employee applications. 

The most notable achievements are secure end-to-end communication be- 
tween service provider and subscriber, server-side application execution that 
allows for much more flexibility and interactivity, and the management of per- 
sistent storage for service providers. 
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Abstract. This paper presents a novel approach to the problem of byte- 
code verification for Java Card applets. Owing to its low memory require- 
ments, our verification algorithm is the first that can be embedded on 
a smart card, thus increasing tremendously the security of post-issuance 
downloading of applets on Java Cards. 



1 Introduction 

The Java Card architecture for smart cards [4] bring two major innovations 
to the smart card world: first, Java cards can run multiple applications, which 
can communicate through shared objects; second, new applications, called ap- 
plets^ can be downloaded on the card post issuance. These two features bring 
considerable flexibility to the card, but also raise major security issues. A mali- 
cious applet, once downloaded on the card, can mount a variety of attacks, such 
as leaking confidential information outside (e.g. PINs and secret cryptographic 
keys), modifying sensitive information (e.g. the balance of an electronic purse), 
or interfering with other honest applications already on the card, causing them 
to malfunction. 

The security issues raised by applet downloading are well known in the area 
of Web applets, and more generally mobile code for distributed systems [23,11]. 
The solution put forward by the Java programming environment is to execute 
the applets in a so-called “sandbox”, which is an insulation layer preventing 
direct access to the hardware resources and implementing a suitable access con- 
trol policy [7]. The security of the sandbox model relies on the following three 
components: 

1. Applets are not compiled down to machine executable code, but rather to 
bytecode for a virtual machine. The virtual machine manipulates higher- 
level, more secure abstractions of data than the hardware processor, such as 
object references instead of memory addresses. 

2. Applets are not given direct access to hardware resources such as the se- 
rial port, but only to a carefully designed set of API classes and methods 
that perform suitable access control before performing interactions with the 
outside world on behalf of the applet. 

3. Upon downloading, the bytecode of the applet is subject to a static analysis 
called bytecode verification, whose purpose is to make sure that the code 
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of the applet is well typed and does not attempt to bypass protections 1 
and 2 above by performing ill-typed operations at run-time, such as forging 
object references from integers, illegal casting of an object reference from 
one class to another, calling directly private methods of the API, jumping in 
the middle of an API method, or jumping to data as if it were code [8,24,10]. 

The Java Card architecture features components 1 and 2 of the sandbox model: 
applets are executed by the Java Card virtual machine [22], and the Java Card 
runtime environment [21] provides the required access control, in particular 
through its “firewall”. However, component 3 (the bytecode verifier) is miss- 
ing: as we shall see later, bytecode verification as it is done for Web applets is 
a complex and expensive process, requiring large amounts of working memory, 
and therefore believed to be impossible to implement on a smart card. 

Several approaches have been considered to palliate the lack of on-card byte- 
code verification. The first is to rely on off-card tools (such as trusted compilers 
and converters, or off-card bytecode verifiers) to produce well- typed bytecode 
for applets. A cryptographic signature then attests the well-typedness of the ap- 
plet, and on-card downloading is restricted to signed applets. The drawback of 
this approach is to extend the trusted computing base to include off-card com- 
ponents. The cryptographic signature also raises delicate practical issues (how 
to deploy the signature keys?) and legal issues (who takes liability for a buggy 
applet produced by faulty off-card tools?). 

The second workaround is to perform type checks dynamically, during the 
applet execution. This is called the defensive virtual machine approach. Here, 
the virtual machine not only computes the results of bytecode instructions, but 
also keeps track of the types of all data it manipulates, and performs additional 
safety checks at each instruction. The drawbacks of this approach is that dy- 
namic type checks are expensive, both in terms of execution speed and memory 
requirements (storing the extra typing information takes significant space). Ded- 
icated hardware can make some of these checks faster, but does not reduce the 
memory requirements. 

Our approach is to challenge the popular belief that on-card bytecode ver- 
ification is unfeasible. In this paper, we describe a novel bytecode verification 
algorithm for Java Card applets that is simple enough and has low enough mem- 
ory requirements to be implemented on a smart card. A distinguishing feature of 
this algorithm is to rely on off-card bytecode transformations whose purpose is 
to facilitate on-card verification. Along with auxiliary consistency checks on the 
CAP file structure, not described in this paper for lack of space, the bytecode 
verifier described in this paper is at the heart of the Trusted Logic on-card CAP 
file verifier. This product - the first and currently only one of its kind - allows 
secure execution with no run-time speed penalty of non-signed applets on Java 
cards. 

The remainder of this paper is organized as follows. Section 2 reviews the 
traditional bytecode verification algorithm, and analyzes why it is not suitable 
to on-card implementation. Section 3 presents our bytecode verification algo- 
rithm and how it addresses the issues with the traditional algorithm. Section 
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4 describes the off-card code transformations that transform any correct applet 
into an equivalent applet that passes on-card verification. Section 5 gives pre- 
liminary performance results. Related work is discussed in section 6, followed by 
concluding remarks in section 7. 

2 Traditional Bytecode Verification 

In this section, we review the traditional bytecode verification algorithm devel- 
oped at Sun by Gosling and Yellin [8,24,10]. 

Bytecode verification is performed on the code of each non-abstract method 
in each class of the applet. It consists in an abstract execution of the code of the 
method, performed at the level of types instead of values as in normal execution. 
The verifier maintains a stack of types and an array associating types to registers 
(local variables). These stack and array of registers parallel those found in the 
virtual machine, except that they contain types instead of values. 

2.1 Straight-Line Code 

Assume first that the code of the method is straight line (no branches, no ex- 
ception handling). The verifier considers every instruction of the method code 
in turn. For each instruction, it checks that the stack before the execution of the 
instruction contains enough entries, and that these entries are of the expected 
types for the instruction. It then simulates the effect of the instruction on the 
stack and registers, popping the arguments, pushing back the types of the re- 
sults, and (in case of “store” instructions) updating the types of the registers to 
reflect that of the stored values. Any type mismatch on instruction arguments, 
or stack underflow or overflow, causes verification to fail and the applet to be 
rejected. Finally, verification proceeds with the next instruction, until the end 
of the method is reached. 

The stack type and register types are initialized to reflect the state of the 
stack and registers on entrance to the method: the stack is empty; registers 
0, . . . , n — 1 holding method parameters and the this argument if any are given 
the corresponding types, as given by the descriptor of the method; registers 
n, . . . , m — 1 corresponding to uninitialized registers are given the special type T 
corresponding to an undefined value. 



2.2 Dealing with Branches 

Branch instructions and exception handlers introduce forks (execution can con- 
tinue down several paths) and joins (several such paths join on an instruction) 
in the flow of control. To deal with forks, the verifier cannot in general determine 
the path that will be followed at run-time. Hence, it must propagate the inferred 
stack and register types to all possible successors of the forking instruction. Joins 
are even harder: an instruction that is the target of one or several branches or 
exception handlers can be reached along several paths, and the verifier has to 
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make sure that the types of the stack and the registers along all these paths agree 
(same stack height, compatible types for the stack entries and the registers). 

Sun’s verification algorithm deals with these issues in the manner custom- 
ary for data flow analyses. It maintains a data structure, called a “dictionary” , 
associating a stack and register type to each program point that is the target 
of a branch or exception handler. When analyzing a branch instruction, or an 
instruction covered by an exception handler, it updates the type associated with 
the target of the branch in the dictionary, replacing it by the least upper bound 
of the type previously found in the dictionary and the type inferred for the 
instruction. (The least upper bound of two types is that smallest type that is 
assignment-compatible with the two types.) If this causes the dictionary entry to 
change, the corresponding instructions and their successors must be re-analyzed 
until a fixpoint is reached, that is, all instructions have been analyzed at least 
once without changing the dictionary entries. See [10, section 4.9] for a more 
detailed description. 

2.3 Performance Analysis 

The verification of straight-line pieces of code is very efficient, both in time and 
space. Each instruction is analyzed exactly once, and the analysis is fast (approx- 
imately as fast as executing the instruction in the virtual machine). Concerning 
space, only one stack type and one set of register types need to be stored at 
any time, and is modified in place during the analysis. Assuming each type is 
represented by 3 bytes, this leads to memory requirements of 3S + 3N bytes, 
where S is the maximal stack size and N the number of registers for the method. 
In practice, 100 bytes of RAM suffice. Notice that a similar amount of space is 
needed to execute an invocation of the method; thus, if the card has enough 
RAM space to execute the method, it also has enough space to verify it. 

Verification in the presence of branches is much more costly. Instructions may 
need to be analyzed several times in order to reach the fixpoint. Experience shows 
that few instructions are analyzed more than twice, and many are still analyzed 
only once, so this is not too bad. The real issue is the memory space required to 
store the dictionary. If B is the number of distinct branch targets and exception 
handlers in the method, the dictionary occupies (35' + 3N 3) x B bytes (the 
three bytes of overhead per dictionary entry correspond to the PC of the branch 
target and the stack height at this point). A moderately complex method can 
have 5 = 5, A = 15 and 5 = 50, for instance, leading to a dictionary of size 
3450 bytes. This is too large to fit comfortably in RAM on current generation 
Java cards. 

Storing the dictionary in persistent rewritable memory (EEPROM or Plash) 
is not an option, because verification performs many writes to the dictionary 
when updating the types it contains (typically, several hundreds, even thousands 
of writes for some methods), and these writes to persistent memory take time 
(1-10 ms each); this would make on-card verification too slow. Moreover, prob- 
lems may arise due to the limited number of write cycles permitted on persistent 
memory. 
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3 Our Verification Algorithm 

3.1 Intuitions 

The novel bytecode verification algorithm that we describe in this paper follows 
from a careful analysis of the shortcomings of Sun’s algorithm, namely that a 
copy of the stack type and register type is stored in the dictionary for each 
branch target. Experience shows that dictionary entries are quite often highly 
redundant. In particular, it is very often the case that stack types stored in 
dictionary entries are empty, and that the type of a given register is the same in 
all or most dictionary entries. 

These observations are easy to correlate with the way current Java compilers 
work. Concerning the stack, all existing compilers use the stack only for evalu- 
ating expressions, but never store the values of Java local variables on the stack. 
Consequently, the stack is empty at the beginning and the end of every state- 
ment. Since most branching constructs in the Java language work at the level of 
statements, the branches generated when compiling these constructs naturally 
occur in the context of an empty stack. The only exception is the conditional ex- 
pression ei ? 02 : 03, which indeed generates a branch on a non-empty stack. 
As regards to registers, Java compilers very often allocate a distinct JCVM reg- 
ister for each local variable in the Java source. This register is naturally used 
with only one type, that of the declaration of the local variable. 

Of course, there is no guarantee that the JCVM code given to the verifier 
will enjoy the two properties mentioned above (stack is empty at branch points; 
registers have only one type throughout the method), but these two properties 
hold often enough that it is justified to optimize the bytecode verifier for these 
two conditions. 

One way to proceed from here is to design a data structure for holding the 
dictionary that is more compact when these two conditions hold. For instance, 
the “stack is empty” case could be represented specially, and differential encod- 
ings could be used to reduce the dictionary size when a register has the same 
type in many entries. 

We decided to take a more radical approach and require that all JCVM 
bytecode accepted by the verifier is such that 

— Requirement Rl: the stack is empty at all branch instructions (after pop- 
ping the branch arguments, if any), and at all branch target instructions 
(before pushing its results). This guarantees that the stack is consistent be- 
tween the source and the target of any branch (since it is empty at both 
ends). 

— Requirement R2: each register has only one type throughout the method 
code. This guarantees that the types of registers are consistent between 
source and target of each branch (since they are consistent between any 
two instructions, actually). 

To avoid rejecting correct JCVM code that happens not to satisfy these two 
requirements, we will rely on a general off-card code transformation that trans- 
forms correct JCVM code into equivalent code meeting these two additional 
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requirements. The transformation is described in section 4. We rely on the fact 
that the violations of requirements R1 and R2 are infrequent to ensure that the 
code transformations are minor and do not cause a significant increase in code 
size. 



3.2 The Algorithm 

Given the two additional requirements R1 and R2, our bytecode verification 
algorithm is a simple extension of the algorithm for verifying straight-line code 
outlined in section 2.1. As previously, the only data structure that we need is 
one stack type and one array of types for registers. As previously, the algorithm 
proceeds by examining in turn every instruction in the method, in code order, 
and reflecting their effects on the stack and register types. The complete pseudo- 
code for the algorithm is given in Fig. 1. The significant differences with straight- 
line code verification are as follows. 

— When checking a branch instruction, after popping the types of the argu- 
ments from the stack, the verifier checks that the stack is empty, and rejects 
the code otherwise. When checking an instruction that is a branch target, 
the verifier checks that the stack is empty. (If the instruction is a JSR target 
or the start of an exception handler, it checks that the stack consists of one 
entry of type “return address” or the exception handler’s class, respectively.) 
This ensures requirement Rl. 

— When checking a “store” instruction, if r is the type of the stored value (the 
top of the stack before the “store” ) , the type of the register stored into is not 
replaced by r, but by the least upper bound of r and the previous type of the 
register. This way, register types accumulate the types of all values stored 
into them, thus progressively determining the unique type of the register as 
it should apply to the whole method code (requirement R2). 

— Since the types of registers can change following the type-checking of a 
“store” instruction as described above, and therefore invalidate the type- 
checking of instructions that load and use the stored value, the type-checking 
of all the instructions in the method body must be repeated until the register 
types are stable. This is similar to the fixpoint computation in Sun’s verifier. 

— The dataflow analysis starts, as previously, with an empty stack type and 
register types corresponding to method parameters set to the types indicated 
in the method descriptor. Locals not corresponding to parameters are set to 
T (the subtype of all types) instead of T (the supertype of all types) for 
reasons that are explained in section 3.4 below. 

The correctness of our verifier was formally proved using the Coq theorem prover. 
More precisely, we developed a mechanically-checked proof that any code that 
passes our verifier does not cause any run-time type error when run through a 
type- level abstract interpretation of a defensive JCVM. 
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Global variables: 

Nr number of registers 
Ns maximal stack size 
r[Nr] array of types for registers 
s[Ns] stack type 
sp stack pointer 

chg flag recording whether r changed. 

Set sp ^ Q 

Set r[0], . . . , r[n — 1] to the types of the method arg. 

Set r[n], . . . ,r[Nr — 1 ] to _L 
Set chg ^ true 
While chg: 

Set chg ^ false 

For each instruction i of the method, in code order: 

If i is the target of a branch instruction: 

If sp 0 and the previous instruction falls through, error 
Set sp ^ 0 

If i is the target of a JSR instruction: 

If the previous instruction falls through, error 
Set s[0] ^ retaddr and sp ^ 1 
If z is a handler for exceptions of class C: 

If the previous instruction falls through, error 
Set s[0] ^ (7 and sp ^ 1 

If two or more of the cases above apply, error 

Determine the types ai,...,an of the arguments of i 
If sp < n, error (stack underflow) 

For k = l,...,n: If s[sp — n — k — 1 ] is not subtype of a/t , error 

Set sp ^ sp — n 

Determine the types of the results of i 

If sp-\-m>Nsi error (stack overflow) 

For k = l,...,m: Set s[sp k — 1 ] ^ Vk 

Set sp ^ sp m 

If z is a store to register number n: 

Determine the type t of the value written to the register 
Set r[rz] ^ lub(t, r[n]) 

If r[n] changed, set chg ^ true 

If z is a branch instruction and spy^O, error 

End for each 
End while 

Verification succeeds 



Fig. 1. The verification algorithm 
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3.3 Performance Analysis 

Our verification algorithm has the same low memory requirements as straight- 
line code verification: 35' + 3N bytes of RAM suffice to hold the stack and 
register types. In practice, it fits comfortably in 100 bytes of RAM. The memory 
requirements are independent of the size of the method code, and of the number 
of branch targets. 

Time behavior is similar to that of Sun’s algorithm: several passes over the 
instructions of the method may be required; experimentally, most methods need 
only two passes (the first determines the types of the registers and the second 
checks that the fixpoint is reached), and quite a few need only one pass (when all 
registers are parameters and they keep their initial type throughout the method). 



3.4 Initialization of Registers 

Unlike Sun’s, our verification algorithm cannot guarantee that registers are ini- 
tialized (stored into) before use. The reason is that since we have only one set of 
register types for the whole method, we cannot analyze precisely the situation 
where a register is initialized on one branch of a conditional and not on the other 
branch. 

The JVM and JCVM specifications do not require the virtual machine to 
initialize non-parameter registers on entry to a method. Hence, a method that 
reads (using the ALOAD instruction) from such a register before having stored a 
valid value in it could obtain an unspecified bit pattern (whatever data happens 
to be in RAM at the location of the register) and use it as an object reference. 
This is a serious security threat. 

There are two ways to avoid this threat. One is to verify register initialization 
(no reads before a store) statically, as part of the bytecode verifier. The other is 
to rely on the virtual machine to initialize, on entry to a method, all registers 
that are not method parameters to the bit-pattern representing the null object 
reference. This way, incorrect code that perform a read before write on a register 
does not break type safety: all instructions operating on object references test 
for the null reference and raise an exception if appropriate; integer instructions 
can operate on arbitrary bit patterns without breaking type safety. (A dynamic 
check must be added to the RET instruction, however, so that a RET on a register 
initialized to null will fail instead of jumping blindly to the null code address.) 

Clearing registers on method entrance is inexpensive, and it is our under- 
standing that several implementations of the JCVM already do it (even if the 
specification does not require it) in order to reduce the life-time of sensitive data 
stored on the stack. In summary, register initialization is a rare example of a type 
safety property that is easy and inexpensive to ensure dynamically in the virtual 
machine. Hence, we chose not to ensure it statically by bytecode verification. 

Since the bit pattern representing null is a correct value of any JCVM type 
(short, int, array and reference types, and return addresses), it semantically 
belongs to the type T that is subtype of all other JCVM types. Hence, assuming 
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initialization to null in the virtual machine, it is semantically correct to as- 
sign the initial type ± to registers that are not parameters, like our verification 
algorithm does. 



3.5 Subroutines 

Subroutines are shared code fragments built from the JSR and RET instructions 
and used for compiling the try. . . finally construct in particular [ 10 ]. Subrou- 
tines complicate Sun-style bytecode verification tremendously. The reason is that 
a subroutine can be called from different contexts, where registers have different 
types; checking the type-correctness of subroutine calls therefore requires that 
the verification of the subroutine code be polymorphic with respect to the types 
of the registers that the subroutine body does not use [10, section 4.9.6]. This 
requires a complementary code analysis that identifies the method instructions 
that belong to subroutines, and match them with the corresponding JSR and 
RET instructions. See [19,17] for formalizations of this approach. 

All these complications (and potential security holes) disappear in our byte- 
code verification algorithm: since it ensures that a register has the same type 
throughout the method code, it ensures that the whole method code, including 
subroutines, is monomorphic with respect to the types of all registers. Hence, 
there is no need to verify the JSR and RET instructions in a special, polymorphic 
way: JSR is treated as a regular branch that also pushes a value of type “return 
address” on the stack; and RET is treated as a branch that can go to any in- 
struction that follows a JSR in the current method. No complementary analysis 
of the subroutine structure is required. 

4 Off-Card Code Transformations 

As explained in section 3.1, our on-card verifier accepts only a subset of all 
type-correct applets: those whose code satisfies the two additional requirements 
R1 (stack is empty at branch points) and R2 (registers have unique types). To 
ensure that all correct applets pass verification, we could compile them with a 
special Java compiler that generates JVM bytecode satisfying requirements R1 
and R2, for instance by expanding conditional expressions ei ? 62 : 63 into 
if . . . then. . . else statements, and by assigning distinct register to each source- 
level local variable. 

Instead, we found it easier and more flexible to let applet developers use 
a standard Java compiler and JavaCard converter of their choice, and perform 
an off-card code transformation on the compiled code to produce an equivalent 
compiled code that satisfies the additional requirements R1 and R 2 and can 
therefore pass the on-card verifier (see Fig. 2). 

Two main transformations are performed: stack normalization (to ensure 
that the stack is empty at branch points) and register reallocation (to ensure 
that a given register is used with only one type). 
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Off- card processing On- card processing 

Fig. 2. Architecture of the system 



4.1 Stack Normalization 



The idea underlying stack normalization is quite simple: whenever the original 
code contains a branch with a non-empty stack, we insert stores to fresh regis- 
ters before the branch, and loads from the same registers at the branch target. 
This effectively empties the stack into the fresh registers before the branch, and 
restore the stack to its initial state after the branch. Consider for example the 
following Java statement: C.m(b ? x : y) ; . It compiles down to the JCVM 
code fragment shown below on the left. 



sload Lb 
ifeq Ibll 
sload Lx 
goto lbl2 
Ibll: sload Ly 
lbl2: invokestatic C.m 



sload Lb 
ifeq Ibll 
sload Lx 
sstore Ltmp 
goto lbl2 
Ibll: sload Ly 

sstore Ltmp 
lbl2 : sload Ltmp 

invokestatic C.m 



Here, Lx, Ly and Lb are the numbers for the registers holding x, y and b. The 
result of type inference for this code indicates that the stack is non-empty across 
the goto to lbl2: it contains one entry of type short. Stack normalization 
therefore rewrites it into the code shown above on the right, where Ltmp is the 
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number of a fresh, unused register. The s store Ltmp before goto lbl2 empties 
the stack, and the sload Ltmp at lbl2 restore it before proceeding with the 
invokestatic. Since the sload Ly at Ibll falls through the instruction at lbl2, 
we must treat it as an implicit jump to lbl2 and also insert a s store Ltmp 
between the sload Ly and the instruction at lbl2. 

(Allocating fresh temporary registers such as Ltmp for each branch target 
needing normalization may seem wasteful. Register reallocation, as described in 
section 4.2, is able to “pack” these variables, along with the original registers of 
the method code, thus minimizing the number of registers really required.) 

By lack of space, we omit a detailed presentation of the actual stack normal- 
ization transformation. It follows the approach outlined above, with some extra 
complications due to branch instructions that pop arguments off the stack, and 
also to the fact that a branch instruction needing normalization can be itself the 
target of another branch instruction needing normalization. 



4.2 Register Reallocation 

The second code transformation performed off-card consists in re-allocating reg- 
isters (i.e. change the register numbers) in order to ensure requirement R2: a 
register is used with only one type throughout the method code. This can al- 
ways be achieved by “splitting” registers used with several types into several 
distinct registers, one per use type. However, this can increase markedly the 
number of registers required by a method. 

Instead, we use a more sophisticated register reallocation algorithm, derived 
from the well-known algorithms for global register allocation via graph color- 
ing. This algorithm tries to reduce the number of registers by reusing the same 
register as much as possible, i.e. to hold source variables that are not live si- 
multaneously and that have the same type. Consequently, it is very effective at 
reducing inefficiencies in the handling of registers, either introduced by the stack 
normalization transformation, or left by the Java compiler. 

Consider the following example (original code on the left, result of register 
reallocation on the right). 



sconst_l 


sconst_l 


sstore 1 


sstore 1 


sload 1 


sload 1 


sconst_2 


sconst_2 


sadd 


sadd 


sstore 2 


sstore 1 


new C 


new C 


astore 1 


astore 2 



In the original code, register 1 is used with two types: first to hold values of 
type short, then to hold values of type C. In the transformed code, these two 
roles of register 1 are split into two distinct registers, 1 for the short role and 2 
for the C role. In parallel, the reallocation algorithm notices that, in the original 
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code, register 2 and the short role of register 1 have disjoint live ranges and 
have the same type. Hence, these two registers are merged into register 1 in the 
transformed code. The end result is that the number of registers stays constant. 

The register reallocation algorithm is essentially identical to Briggs’ variant 
of Chaitin’s graph coloring allocator [3,1], with additional type constraints re- 
flecting requirement R2. More precisely, we add edges in the interference graph 
between live ranges that do not have the same principal type, thus guaranteeing 
that they will be assigned different registers. 

5 Experimental Results 

5.1 Off-Card Transformation 

The table below shows results obtained by transforming 6 packages from Sun’s 
Java Card development kit. 



Package 


Code size (bytes) 


Resident size 


(bytes) 


Registers 


Orig. 


Transf. 


Incr. 


Orig. 


Transf. 


Incr. 


java. lang 


92 


91 


-1% 


320 


319 


-0.3% 


0.0% 


j avacard . framework 


4047 


4142 


+2.3% 


5393 


5488 


+1.8% 


+0.3% 


com . sun . j avacard . HelloWorld 


100 


99 


-1% 


220 


219 


-0.5% 


0.0% 


com . sun . j avacard . JavaPurse 


2558 


2531 


-1% 


3045 


3018 


-0.8% 


-8.3% 


com . sun . j avacard . JavaLoyalty 


207 


203 


-1.9% 


365 


361 


-1% 


0.0% 


com . sun . j avacard . installer 


7043 


7156 


+1.6% 


8625 


8738 


+1.3% 


-7.5% 


Total 


14047 


14222 


+1.2% 


17968 


18143 


+0.9% 


-4.2% 



The code size increase caused by the transformation is almost negligible: the 
size of the Method component increases by 1.2%; the resident size (total size of 
all components that remain on the card after installation) increases by 0.9%. 
The requirements in registers globally decreases by about 4%. 

To test a larger body of code, we used a version of the off-card transformer 
that works over Java class files (instead of Java Card CAP files) and transformed 
all the classes from the Java Runtime Environment version 1.2.2, that is, about 
1.5 Mbyte of JVM code. The results are very similar: code size increases by 0.7%; 
registers decrease by 1.3%. 

The transformer performs clean-up optimizations (branch tunneling, register 
coalescing) whose purpose is to reduce inefficiencies introduced by other trans- 
formations. These optimizations are also quite effective at reducing inefficiencies 
left by the Java compiler, resulting in code size decreases of up to 1.9% for 
some packages. Similarly, the packing of registers actually reduces the maximal 
number of registers in most packages. 



5.2 On-Card Verifier 

We present here preliminary results obtained on an implementation of our byte- 
code verifier running on a Linux PC. A proper on-card implementation is in 
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progress, but we are not in a position to give results concerning this implemen- 
tation. 

Bytecode verification proper (ensuring that method code is type-safe), writ- 
ten in ANSI C, compiles down to 11 kilobytes of Intel IA32 code, and 9 kilobytes 
of Atmel AVR code. A proof-of-concept reimplementation in hand-written ST7 
assembly code fits in 4.5 kilobytes of code. 

In addition to verifying the bytecode of methods, our implementation also 
checks the structural consistency of CAP file components. Since the CAP file 
format is extremely complex [22, chapter 6], CAP file consistency checking takes 
a whopping 12 kilobytes of Intel IA32 code. However, when integrating the ver- 
ifier with an actual Java Card VM, many of these consistency checks become 
redundant with checks already performed by the VM or the installer, or useless 
because they apply to CAP file information that the VM ignores. Programming 
tricks such as table-driven automata can also be used to reduce further the code 
size of consistency checking, at some expense in execution speed. 

The PC implementation of the verifier, running on a 500 Mhz Pentium III, 
takes approximately 1.5 ms per kilobyte of bytecode. Extrapolating this figure 
to a typical 8-byte smartcard processor (e.g. 8051 at 5 Mhz), we estimate that an 
on-card implementation should take less than 1 second per kilobyte of bytecode, 
or about 2 seconds to verify an applet the size of JavaPurse. Notice that the 
verifier performs no EEPROM writes and no communications, hence its speed 
benefits linearly from higher clock rates or more efficient processor cores. 

Concerning the number of iterations required to reach the fixpoint in the 
bytecode verification algorithm, the 6 packages we studied contain 7077 JCVM 
instructions and require 11492 calls to the function that analyzes individual 
instructions. This indicates that each instruction is analyzed 1.6 times on average 
before reaching the fixpoint. This figure is surprisingly low; it shows that a 
“perfect” verification algorithm that analyzes each instruction exactly once, such 
as [18], would only be 38% faster than ours. 

6 Related Work 

The work most closely related to ours is the lightweight bytecode verification 
of Rose and Rose [18], also found in the KVM architecture [20] and in [9]. 
Inspired by proof-carrying code [12], lightweight bytecode verification consists 
in sending, along with the code to be verified, pre-computed stack and register 
types for each branch target. Verification then simply checks the correctness of 
these pre-computed types, using a simple variant of straight-line verification, 
instead of inferring them by fixpoint iteration, as in Sun’s verifier. 

The interest for an on-card verifier is twofold. The first is that fixpoint it- 
eration is avoided, thus making the verifier faster. (As mentioned at the end 
of section 5.2, the performance gain thus obtained is modest.) The second is 
that the stack and register types at branch targets can be stored temporarily in 
EEPROM, since they do not need to be updated repeatedly during verification. 
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The RAM requirements of the verifier become similar to those of our verifier: 
only the current stack type and register type need to be kept in RAM. 

There are two problems with Rose and Rose’s lightweight bytecode verifica- 
tion. One is that it currently does not deal with subroutines, more specifically 
with polymorphic typing of subroutines as described in section 3.5. Subroutines 
are part of the JCVM specification, and could be useful as a general code sharing 
device for reducing bytecode size. The second issue is the size of the “certificate” , 
that is, the pre-computed stack and register types that accompany the code. Our 
experiments indicate that, using a straightforward representation, certificates are 
about the same size as the code. Even with a more complex, compressed repre- 
sentation, certificates are still 20% of the code size. Hence, significant free space 
in EEPROM is required for storing temporarily the certificates during the veri- 
fication of large packages. In contrast, our verification technology only requires 
at most 1-2% of extra EEPROM space. 

Challenged by the lack of precision in the reference publications of Sun’s 
verifier [8,24,10], many researchers have published rational reconstructions, for- 
malizations, and formal proofs of correctness of various subsets of Sun’s veri- 
fier [5,16,15,17,6,13]. These works were influential in understanding the issues, 
uncovering bugs in Sun’s implementation of the verifier, and generating confi- 
dence in the algorithm. Unfortunately, most of these works address only a subset 
of the verifier. In particular, none of them proves the correctness of Sun’s poly- 
morphic typing of subroutines in the presence of exceptions. 

A different approach to bytecode verification was proposed by Posegga [14] 
and further refined by Brisset [2]. This approach is based on model checking 
of a type- level abstract interpretation of a defensive Java virtual machine. It 
trivializes the problem with polymorphic subroutines and exceptions, but is very 
expensive (time and space exponential in the size of the method code), thus is 
not suited to on-card implementation. 

7 Conclusions 

The novel bytecode verification algorithm described in this paper is perfectly 
suited to on-card implementation, due to its low RAM requirements. It is su- 
perior to Rose and Rose’s lightweight bytecode verification in that it handles 
subroutines, and requires much less additional EEPROM space (1-2% of the 
code size vs. 20-100% for lightweight bytecode verification). 

On-card bytecode verification is the missing link in the Javacard vision of 
multi-application smart cards with secure, efficient post-issuance downloading 
of applets. We believe that our bytecode verifier is a crucial enabling technology 
for making this vision a reality. 
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Abstract. This paper reports on ongoing work to develop a formal spec- 
ification of the JavaCard API using the specification language JML. 
It discusses the specification of the JCSystem class, which deals with 
the JavaCard firewall, (atomic) transactions and transient objects. The 
JCSystem class seems to be the hardest class in the API to specify, and 
it is closely connected with some of the peculiarities of JavaCard as 
opposed to Java. 



1 Introduction 

There has been a lot of work on formalisations of the Java (Card) platform. 
(Eor a comprehensive overview see [4].) However, most of the work has concen- 
trated on the Java (Card) Virtual Machine, and there has only been very little 
work on formalisations of the other component of the JavaCard platform, the 
JavaCard API. This paper reports on an ongoing effort to develop a formal 
specification of the JavaCard API using the specification language JML. Our 
ultimate goal is to use a formal specification of the API to verify API imple- 
mentations and to use it as a basis for the verification of JavaCard applets. 
But of course a formal specification of the API is of wider interest, notably to 
improve and clarify existing informal documentation. Eor verification we want 
to use the LOOP tool developed in Nijmegen [1], which gives a formal seman- 
tics to Java programs and acts as a front-end to the theorem prover PVS. The 
first — very modest — steps to verify JML-annotated JavaCard code using the 
LOOP tool and the theorem prover PVS are reported in [2]. 

Earlier work on ‘lightweight’ formal JML specifications for the Java- 
Card API is reported in [13,14]. This paper discusses the specification of the 
JCSystem class, which is the class in the API that deals with the JavaCard fire- 
wall, (atomic) transactions and transient objects. The JCSystem class seems to 
be the most difficult class in the API to specify, as it cannot be described com- 
pletely independently of some basic features of the JavaCard Virtual Machine. 
The class is closely connected with some of the peculiarities of JavaCard as 
opposed to Java. 

This work is part of the EU-sponsored VERlFiCARD-project which aims to 
provide formal descriptions of the JavaCard platform and to provide tools 
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for applet verification based on these formal descriptions. (For more details see 
http : //www. verif icard. org.) 



2 JML 



JML [8,9] is a behavioural interface specification language tailored to Java. It 
can be used to specify Java classes and interfaces by annotating code with in- 
variants and pre- and postconditions of methods, in the style of Eiffel, also known 
as ‘Design by Contract’ [10]. JML annotations are a special kind of Java com- 
ments: they are preceded by //@, or enclosed between /*@ and @*/, so that they 
are simply ignored by a JAVA compiler. 

Methods can be specified in JML by so-called normal behaviours. These are 
of the form: 

/*@ normal_behavior 

@ requires: <precondition> ; 

@ ensures: <postcondition> ; 

@*/ 

Such a ‘normal behaviour’ specification states that if the precondition holds at 
the beginning of a method invocation, then the method terminates normally 
(i.e. without throwing an exception) and the postcondition will hold at the end 
of the method invocation. 

Pre- and postconditions are simply standard Java boolean expressions, ex- 
tended with several additional operators, for example \forall for universal 
quantification and ==> for implication. A few more of these additional opera- 
tions will be explained as we go along. 

Java methods can terminate abruptly, by throwing exceptions. If a method 
can throw an exception, then a more general form of method specification than 
the normal behaviour above is needed: 



/*@ behavior 
@ requires: 
@ ensures : 

@ signals: 



<precondition> ; 
<postcondition> ; 
(Exceptionl) <conditionl> ; 



@ signals: (Exceptionn) <conditionn> ; 
@*/ 



Such a ‘behaviour’ specification states that if the precondition holds at the be- 
ginning of a method invocation, then the method either terminates normally 
or terminates abruptly by throwing one of the listed exceptions; if the method 
terminates normally, then the postcondition will hold; if the method throws an 
exception, then the corresponding condition will hold. 

More than one (normal) behaviour can be specified for a single method. This 
simply means that the method has to satisfy all of the given (normal) behaviours. 
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This is a convenient way to specify different cases in the behaviour of a method. 
The default pre- and postconditions are requires: true and ensures: true, 
and these may be omitted in specifications. 

In addition to requires, ensures and signals clauses, methods specifica- 
tions can also include modifiable clauses. These clauses specify so-called frame 
conditions, which say that only certain fields may have their values changed by 
a method. For example, modifiable :x specifies that a method changes only 
field X. 

One feature of JML that is of particular importance for this paper is the 
possibility of using so-called model fields (or model variables). Model fields are 
declared in JML annotations and provide specification-only variables: they can 
not be used in program code, but only in JML assertions. Typically, model fields 
are introduced to refer to some part of the ‘state’ encapsulated by objects of a 
class, a ‘piece of state’ on which the informal specification implicitly relies, and 
on which the formal JML specification will explicitly rely. As far as the class 
JCSystem discussed in this paper is concerned, the main difficulty in developing 
formal JML specifications is introducing appropriate model fields. 

Ultimately, there should be a relation between the model variables used in 
the specification and variables actually used in the implementation, and this 
relation can again be stated as a JML annotation. Of course, if a method is 
native, which is the case for many methods of JCSystem, there is no concrete 
implementation to which the models variables can be related. 

Normally a model variable and the way its value changes in response to 
invocations of certain methods is completely described by the specifications of 
these methods. However, as will be discussed later, for some model variables 
used in the specification of JCSystem this is not the case. The value of some 
model variables does not only change in response to certain method invocations, 
but can also change as a side-effect of basic JavaCard language constructs. 

3 The JavaCard API 

Together with the JavaCard virtual machine (JCVM), the JavaCard API 
forms the JavaCard runtime environment, or JCRE, as illustrated in Figure 1. 
The JCVM provides the interpretation of the basic JavaCard language, i.e. of 
all the JavaCard language constructs. The API is a collection of classes and 
interfaces providing additional functionality that can be used in JavaCard pro- 
grams. The JavaCard API (version 2.1.1) [5] comprises 18 classes for excep- 
tions, 16 interfaces for working with cryptographic keys and only 10 funda- 
mental classes (in the package javacard. framework). Of these IS07816, Util, 
Applet and Shareable are elementary from a specification perspective, PIN and 
OwnerPIN facilitate working with PIN-codes, and AID is a datatype for the iden- 
tification of applets. 

Part of the JavaCard API - namely the classes APDU and JCSystem - can 
be understood as an interface to the miniature operating system running on 
the smart card. The class APDU is the interface of the device driver handling 
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Fig. 1. The JavaCard Platform 



communication of the smart card and the card reader, aka the Card Acceptance 
Device (CAD). A (still incomplete) formal specification for APDU is discussed 
in [14]. The class JCSystem provides an interface to the core of the operating 
system, dealing with the firewall, (atomic) transactions and transient objects. 
Its specification is the topic of this paper. 

A diagram such as Figure 1 is somewhat misleading, as it suggests a clear 
division between the JCVM and the API, whereas there is a close connection: 
some parts of the API concern features that are an integral part of the JCVM. It 
would be more accurate to have some overlap between the API and JCVM boxes 
in Figure 1. The one class in the API that would be in this overlap is JCSystem, 
as the functionality it provides is intimately connected with the JCVM. A com- 
plicating factor in understanding the connection between JCVM and API is 
that the specification of the JCVM [7] is given at byte-code level, whereas the 
specification of the API [5] is given at source-code level. The additional JCRE 
specification [6] , which gives the most detailed description of the connection be- 
tween JCVM and API, uses byte code level in some parts and source code in 
others. 

4 JCSystem 

The JCSystem class offers the functionality for 3 basic ingredients of the Java- 
Card platform: 

1. the creation of objects in transient memory which are cleared when the 
applet is deselected or when the card is reset; 

2. atomic transactions enabling the undoing of certain (partial) updates when 
power is lost; 

3. the firewall which restricts the access of an applet’s objects by other applets 
unless explicitly granted. 
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This functionality is embodied in 15 methods (not counting the method 
getVersion which yields the current version number), listed in Figure 2 below. 
These methods may be considered as the system calls of the JavaCard oper- 
ating system by which applets have access to the basic features of JavaCard. 
We will discuss the formal specification of transience and the firewall in some 
detail, and sketch that of atomicity. 

As far as the three features listed above are concerned it is hard to draw a line 
between the API and the JavaCard language (or the JCVM). Unlike the other 
API classes the class JCSystem does not provide a piece of functionality that 
provides an addition to the bare JCVM and that can be understood in isolation, 
as the three features are really an integral part of the JavaCard language. 
This is what makes the specification of JCSystem essentially more difficult than 
the specification of the other API classes. Indeed, the class JCSystem is not 
only specified in Sun’s API specification [5], but is also extensively discussed 
in the JavaCard Runtime Environment (JCRE) specification [6]. A still more 
detailed description is given by Sun’s Java reference implementation of the 
JavaCard API. In particular, the reference implementation of Sun includes 
a class Dispatcher that does not contain any public fields or methods and is 
therefore not included in the API specification. It contains the main method 
which performs card initialization (creates fundamental objects like the APDU 
buffer and installs built-in applets; it is called only once) and card reset (at 
each power up), and drives the main loop of the card, which processes APDUs 
resulting in the (de)selection of applets or the dispatching of APDUs to or from 
the currently selected applet. 

The basis for our formal JML specification of JCSystem is provided by the 
three sources of information mentioned above: the (informal) JavaCard API 
specification [5], the JavaCard Runtime Environment (JCRE) specification [6], 
and Sun’s reference implementation of the API. The following sections discuss 
the different parts of JCSystem, dealing with transient objects, the firewall, and 
the transaction mechanism, in more detail. 

4.1 Transient Objects 

The JavaCard platform assumes the presence of both persistent memory which 
retains data even if power is lost, and transient memory which is cleared upon 
power loss. When objects are created by the new operator, they are allocated in 
persistent memory. The class JCSystem provides methods for creating objects in 
transient memory; these objects are always arrays. 

The method 

makeTransientBooleanArray (short length, byte event) 

creates (allocates) an array of booleans of the given length in transient memory. 
The array is persistent in the sense that it survives card resets, but its contents 
are cleared (i.e. set to false) when the card is reset (e.g. after power loss), or 
when the applet which created it is deselected. This choice is determined by the 
parameter event, which can be CLEAR_ON_RESET or CLEAR_ON_DESELECT. 
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public final class JCSystem { 
public static short getVersionO ; 

/♦ methods for transient objects ♦/ 

public static native byte isTransient (Object theObj); 

public static native boolean [] makeTransientBooleanArray (short length, 

byte event) ; 

public static native byte [] makeTransientByteArray (short length, 

byte event) ; 

public static native short [] makeTransientShort Array (short length, 

byte event) 

public static native Object [] makeTransientObject Array (short length, 

byte event) ; 



/♦ methods for the transaction mechanism ♦/ 

public static native void beginTransactionO throws Transact ionExcept ion; 
public static native void abortTransactionO throws Transact ionExcept ion; 
public static native void commitTransactionO throws Transact ionExcept ion; 
public static native byte getTransactionDepthO ; 
public static native short getUnusedCommitCapacity () ; 
public static native short getMaxCommitCapacity () ; 

/* methods for the firewall */ 



public static AID getAIDO; 

public static AID lookupAID( byte [] buffer, short offset, byte length ); 
public static AID getPreviousContextAIDO ; 

public static Shareable getAppletShareableInterf aceObject (AID serverAID, 

byte parameter) ; 



} 



Fig. 2. The methods of JCSystem 



The methods makeTransientByteArray, makeTransientShortArray, make- 
TransientObjectArray are completely analogous. The method isTransient 
(Object theObj) yields a byte with value N0T_A_TRANSIENT_0BJECT, 
CLEAR_0N_RESET or CLEAR_ON_DESELECT with the obvious meaning. 

For a formal specification, we first note that a normal behavior of make- 
TransientBooleanArray requires a restriction on the values of its parameters: 
0 < length < free where free is the amount of available free transient memory, 
and event G {CLEAR_0N_RESET, CLEAR_ON_DESELECT}. The firewall imposes addi- 
tional restrictions. The firewall relies on a partitioning of the object system into 
separate objects spaces called eontexts. The JCRE manages a context for each ap- 
plet, and the firewall restricts access across boundaries between these contexts. 
Because of the firewall, the normal behavior of makeTransientBooleanArray 
requires that if event equals CLEAR_ON_DESELECT, the currently active context 
should equal the currently selected context. 

These conditions together constitute the precondition of the normal behav- 
ior of the method. Each possible way to negate this precondition represents 
a precondition of an exceptional behavior, where an exception is thrown. For 
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instance, if length > /ree, a SystemException is thrown with reason code 
SystemException . NO_TRANSIENT_SPACE. 

The postcondition of makeTransientBooleanArray’s normal behavior 
should express that its result is a non-null transient Boolean array with the 
correct length, event and contents (viz. all falses), that free decreases by an 
amount of length^. Finally, the JML operation \f resh can be used to say that 
the result is a ‘freshly’ allocated object. Before writing the actual JML-code of 
this specification, we should note that the variable /ree, the notions ‘currently 
active context’ and ‘currently selected context’, and the ‘event’ property of a 
(transient) object are not directly available when the method is applied. There- 
fore, we introduce JML model variables for free (which we call _f reeTransient) 
as well as for the contexts, and assume that each object has an ‘event’ model field 
telling whether that object is NOTJV_TRANSIENT_OBJECT, or else CLEAR_ON_RESET 
or CLEAR_ON_DESELECT. 

We must make sure when verifying the API and applets that the values 
of these model variables and properties are properly maintained. For instance, 
the increase and decrease of the run-time stack of the JCVM will influence 
_f reeTransient. The ‘currently active context’ can change with a method call, 
and is (in)directly registered in the JCVM run-time-stack. The ‘currently se- 
lected context’ changes with the (de) selection of applets by the dispatcher. In 
some cases (the changes in) the values of model variables and properties can be 
maintained in the JML-specification itself. For instance, one could imagine that 
the value of the ‘currently selected context’ is maintained in the select- and 
deselect-methods of the Applet-class. Otherwise, the maintenance has to be 
built in into the semantics of the relevant JavaCard statements. 

We will not resolve this issue here, and just assume that the appropriate 
(model) variables and properties are available and properly maintained. By con- 
ventions, their names are distinguished by an initial underscore. 

This then results in the JML-specification for makeTransientBooleanArray 
in Figure 3. 

The JavaCard documentation does not specify the behavior in the case 
where length < 0. Whatever class declares _f reeTransient should specify the 
invariant 0 <= _f reeTransient (possibly also giving an upper limit by means 
of a constant jyiAX_SIZE_OF_TRANSIENT). The question may be raised whether 
it is necessary to specify that the allocation is not actually done in persistent 
memory (as is required by the informal specification), or even that the allocation 
does not use memory which is already allocated to other objects. 

The actual clearing of transient arrays should be specified in the dispatcher. 
This may call for a detailed administration of all created transient arrays, ne- 
cessitating an extension of our specification. For instance, we might use a model 
variable _transientMemory modelling the whole transient memory and specify 
the precise allocation in the ensure s-clause of the normal behavior (and make 
_f reeTransient a field of _transientMemory). Alternatively, one could model 

^ Here we possibly oversimplify things a bit, e.g. we ignore any fixed overhead to record 
the length of the array. 
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public static native boolean [] makeTransientBooleanArray (short length, 

byte event) 



throws SystemException; 



normal_behavior 

0 requires: 0 <= length && length <= _f reeTransient && 

0 (event == CLEAR. 0N_RESET | | event == CLEAR_ON_DESELECT) && 

0 (event == CLEAR_ON_DESELECT 

0 ==> .selectedContext == .activeContext) ; 

0 modifiable: _f reeTransient ; 

@ ensures: \result != null && \result . length == length && 

0 \result . .event == event && \fresh(\result) && 

@ .freeTransient == \old(.f reeTransient) - length && 

0 \forall (byte i) 0 <= i < length ==> \result [i] == false; 

0 also 
@ behavior 

0 signals: (SystemException e) 

0 (e . getReasonO == SystemException. ILLEGAL.VALUE && 

0 (length < 0 I I 

0 (event != CLEAR. ON.RESET && event != CLEAR.ON.DESELECT) ) ) 

@ I I 

0 ( e . getReasonO == SystemException. NO.TRANSIENT.SP ACE && 

0 .freeTransient < length) 

@ I I 

0 (e . getReasonO == SystemException. ILLEGAL.TRANSIENT && 

@ event == CLEAR.ON.DESELECT && 

0 .selectedContext != .activeContext) ; 

0 */ 



Fig. 3. JML specification of makeTransientBooleanArray 



a separate transient memory for ‘ clear _on_reset’ arrays and separate transient 
memories for ‘ clear .on.deselect’ arrays for each possible applet, identified by its 

AID. 

The specification of isTransient is rather trivial: 
public static native byte isTransient (Object theObj); 

/*@ behavior 

@ ensures: \result == theObj . .event ; 

@*/ 

4.2 The Firewall 

The firewall mechanism prohibits an applet’s access to objects owned (created) 
by other applets. The rules as detailed in the Java Card Runtime Environment 
(JCRE) specification are quite elaborate. The main principles are that the JCRE 
can access any object, but applets can only access objects owned by applets in the 
same package, objects designated as JCRE entry-point objects, and ‘shareable’ 
objects to which access is explicitly granted by their owners. 

Applets have a certain context, which is basically the package they belong 
to, and the JCRE is considered to have no context. As long as an applet is 
selected, that applet’s context is the currently selected context. When a method 
of an applet is called, that applet’s context becomes the currently active context. 
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public static Shareable getAppletShareableInterf aceObject (AID serverAID, 

byte parameter) 

normal_behavior 

0 requires: _previousContext == _jcreContext && 

0 _registeredAIDs .has (serverAID) ; 

0 ensures: \result == 

0 (_appletTable . apply (serverAID) ) . getShareableInterf aceObject 

0 (null , parameter) ; 

0 also 

0 normal_behavior 

0 requires: _previousContext != _jcreContext && 

0 _registeredAIDs . has (serverAID) ; 

0 ensures: \result == 

0 (_appletTable . apply (serverAID) ) . getShareableInterf aceObject 

0 (getPreviousContextAIDO .parameter) ; 

0 also 

0 normal_behavior 

0 requires: ! _registeredAIDs . has (serverAID) ; 

0 ensures: \result == null; 

0*/ 



Fig. 4. JML specification of getAppletShareableInterf aceObject 



There is also a ‘previous context’ which is the context of the applet which called 
the currently active method, possibly via intermediate JCRE methods. 

JCSystem provides a method 

public static Shareable getAppletShareableInterf aceObject 

(AID serverAID, byte parameter) 

by which an applet may ask permission to access an object owned by 
the applet identified by the given serverAID. It follows from the infor- 
mal API specification [5] (from the specifications of getAppletShareable- 
Interf aceObject of the class JCSystem and of getShareableInterf ace- 
Object of class Applet, to be precise) that this method calls the method 
getShareableInterf aceObject of the applet identified by serverAID, pass- 
ing it the AID of the calling applet (or null if the caller is a JCRE-method) and 
the given parameter. The AID of the calling applet can be obtained using the 
method getPreviousContextAID. If the serverAID is invalid, null is returned. 
Therefore, if the server is valid, and the caller is valid (or the JCRE), the spec- 
ification of getAppletShareableInterf aceObject will be that of the server’s 
getShareableInterf aceObject. 

This is formalized in the JML-specification for getAppletShareable- 
Interf aceObject in Eigure 4. It requires the introduction of more model vari- 
ables, as discussed below. 

The model variable _previousContext is akin to the model variables 
.select edCont ext and .activeContext introduced in Section 4.1. The 
.selectedContext is set and reset when applets are selected and deselected. 
The other two have to be maintained as part of the semantics of the method 
call. In fact, their values could be extracted from the run-time stack. The related 
model constant .jcreContext represents the context of the JCRE; it is different 
from any applet’s context. 
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Two model variables used in the specification of getAppletShareable- 
Interf aceObject are of more complicated types than the model variables seen 
so far. First, there is a model variable _registeredAIDs, which is the set of all the 
aid’s of installed applets. Second, there is a model variable _appletTable, which 
is a partial function from AID’s to applets, that, given an AID, returns the applet 
with that AID, if such an applet is installed. So the domain of _appletTable 
will be _registeredAIDs, and this could in fact be included as an invariant. 
The values of these model variables will change in response to invocations of the 
method register of an applet. 

In specifications one often needs model variables that represents sets and 
functions, such as _registeredAIDs and _appletTable above. For this rea- 
son the JML distribution comes with a package edu. iastate . cs . jml .models 
that implements many mathematical notions that are frequently needed in 
specifications. This package provides suitable classes for _registeredAIDs and 
_appletTable: 

public model JMLObjectSet _registeredAIDs ; 

public model JMLObjectToObjectMap _appletTable ; 

The method has for JMLObjectSet and apply for JMLObjectToObjectMap 
used in the specification of getAppletShareablelnterf aceObject in Fig- 
ure 4 have the obvious interpretations. A detailed description of these 
classes is given as part of the JML release that can be obtained at 
http : //www . cs . iastate . edu/'^leavens/ JML.html. 

Sun’s reference implementation of the JavaCard API provides a particu- 
lar representation of the information in _registeredAIDs, _appletTable, and 
_previousAID. In fact, it uses an array of objects theAppletTable to record 
the mapping _appletTable. Internally, the reference implementation does not 
use AIDs but indexes in this array to identify applets. To ensure that the spec- 
ification is in agreement with this implementation one would use the standard 
technique of establishing an invariant that expresses the correspondence between 
the abstract model variable and the concrete implementation. 

The method lookupAID, by which an applet can obtain AIDs to pass to 
getAppletShareablelnterf aceObject accesses the internal applet table in 
much the same way as getAppletShareablelnterf aceObject and is easy to 
specify. 

The two remaining methods related to the firewall, getAID and 
getPreviousContextAID, return the AIDs associated with the current and 
the previous applet context, respectively. They could be specified by introduc- 
ing model variables _currentContextAID and _previousContextAID, and then 
specifying 

public static AID getPreviousContextAID () 

/*@ normal_behaviour 

@ ensures: \result == _previousContextAID; 

@*/ 
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and similarly for getAID. But observe that there is then effectively no 
difference between getPreviousContextAIDO and the method vari- 
able _previousContextAID. One could simply do away with the model 
variable and use the method instead. (Indeed, the specification of 
getAppletShareableInterf aceObject in Figure 4 already uses the 
method invocation getPreviousContextAIDO rather than some model 
variable _previousContextAID.) Essentially the methods getAID and 
getPreviousContextAID are too fundamental for an interesting specifica- 
tion in JML. 

Something interesting that could still be specified is the relation between 
contexts and AIDs. A model variable for this relation could be introduced 
in order to express the invariants that hold between .current Context and 
.currentContextAID and .previousContext and _previousContextAID. 



4.3 Atomic Transactions 

All updates of single array elements, object fields and class fields in persistent 
memory are atomic. If a failure or power loss occurs during an update, the field 
is restored to its previous value. With modern hardware it is not difficult to obey 
this requirement, and in formal specifications atomic updates are in fact silently 
assumed. The Util-class of the JavaCard API provides methods for atomic 
and non- atomic updates of arrays. 

For more complicated updates, the JCSy stem-class provides the meth- 
ods beginTransactionO , abortTransactionO and commitTransactionO . 
A (hidden) variable transact ionDepth, which is 0 initially, is incre- 
mented by beginTransactionO, decremented by abortTransactionO and 
commitTransactionO, but should always have a value of 0 or 1, otherwise 
a Transact ionExcept ion is thrown. This outlines a behavior specification of 
these methods. 

Essentially, beginTransactionO should create a ‘backup’ of persistent 
memory in a second persistent memory, and abortTransactionO should ‘re- 
store’ it. However, this is not feasible as the amount of persistent memory is 
severely restricted and writing to it is expensive. Therefore, a commit buffer is 
provided, the size of which is implement at ion- dependent. The use of this buffer 
may follow different schemes (as outlined in [12]), of which we just choose one 
(‘old value logging’, as opposed to ‘new value logging’) for our specification. 

Eor each update of a byte of persistent memory, if transact ionDepth > 0, the 
value to be overwritten is recorded in the commit buffer, provided that no value 
is yet recorded for that byte. The buffer is cleared by commitTransactionO, 
but abortTransactionO restores the old values. Also, abortTransactionO is 
implicitly called when the JCRE regains control, upon applet deselection, card 
reset (e.g. after a power loss), or any kind of failure. This may happen even if 
abortTransactionO is in progress. Consequently, from the perspective of the 
applets, the result of such a transaction is always consistently the collection of 
new values or the collection of old values. The atomicity of transactions ulti- 
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mately relies on the fact that the decrease of transact ionDepth is atomic, and 
the last action of abortTransactionO . 

Moreover, any object created during a transaction, either in persis- 
tent or in transient memory, is deleted and has its memory freed upon 
abortTransactionO. Each reference to such an object, even on the run-time 
stack, is set to null. 

In the specification we introduce a (rather complicated) model variable 
_theCommitBuf f er. We assume that the semantics of updates and object cre- 
ation is extended so as to include the recording of old values and pointers in 
this model object. The specification of abortTransactionO will state that the 
values of all object fields and array elements recorded in the commit buffer equal 
those recorded, that any references to newly created objects are set to null and 
that the memory of these objects is freed. 

The specification of three other methods dealing with atomic transac- 
tions, getTransact ionDepth, getUnusedCommitCapacity and getMaxCommit- 
Capacity are quite straightforward. The latter two extract properties from 
_theCommitBuf f er. 

5 Related Work 

Most of the work on formalising the JavaCard platform has focussed on the 
JCVM rather than the API. Still, some (formal) models of transaction mecha- 
nism, firewall, and transient memory have been given. For example, transaction 
mechanisms are described in [15] (using B), [12] and [3] (using Z), and the fire- 
wall in [11] (using B). As mentioned earlier, as far as firewall, atomic actions, 
and transient memory are concerned it is hard to draw a line between the API 
and JCVM, so this work is not unrelated to what we have done. The model 
variables we need in our JML specifications should have counterparts in formal 
descriptions of the JCVM, as explained in more detail below. 

6 Conclusion 

Although some details of the specification of the JavaCard API are some- 
what subtle, the specification as a whole turns out to be rather small. All 
methods have a specification which is not essentially larger than that of 
makeTransientBooleanArray as given in Figure 3. 

The model variables that have to be introduced in our JML specifications 
make explicit many of the informal notions used in the existing informal docu- 
mentation. This can help to clarify and improve these informal specifications. 

Normally, the values of model variables and the way these change in re- 
sponse to methods invocations is completely described by the JML specifica- 
tions. However, for many model variables used in the specification of JCSystem 
this is not the case. Maintaining the correct values of these model variables is 



Towards a Full Formal Specification of the JavaCard API 177 



an integral part of the semantics of normal JavaCard statements. For exam- 
ple, any assignment to a persistent object field that occurs during a transac- 
tion affects _theCommitBuf f er, so the semantics of assignment should include 
this side-effect on _theCommitBuf f er. Or, to give another example, the variable 
_activeContext may need to be changed at every method invocation, so the 
semantics of method invocation should include a side-effect on _activeContext. 
Note that a comprehensive account of all such examples comes down to a spec- 
ification of the differences between Java and JavaCard. 

All this means that ultimately a specification of the JavaCard API cannot 
be considered on its own, but has to be considered together with a formalisation 
of the JavaCard language itself, e.g. a formal description of the JCVM or 
— in our case — our denotational semantics of JavaCard in PVS. The ‘side- 
effects’ mentioned above should then be made part of the implementation of 
certain virtual machine instructions (e.g. invoke bytecodes) c.q. be included in 
the semantics of JavaCard source code statements. The list of model variables 
needed in a formal JML specification gives a good overview of the variables that 
have to be maintained by a JCVM in order to, say, implement the firewall. 

When verifying JavaCard source code using the LOOP tool and PVS, ver- 
ifying any properties that depend on (the model variables of) JCSystem will re- 
quire some mechanism by which (JML) model variables can be associated with 
the external operations they are subject to. How this should be accomplished is 
a matter of further investigation. Note that this issue is not particular to our 
approach to verification using the LOOP tool and PVS: whenever one wants to 
adapt an existing approach of Java- verification to JavaCard the question of 
how to deal with the peculiarities of JavaCard as opposed to Java arises. 
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Abstract. This paper descrihes European standardisation aetivities for the 
evaluation of Seeure Signature Creation Deviees (SSCDs) foeussing on smart 
eards. These standards were delivered this year to the Artiele 9 eommittee in 
aeeordanee to requirements of the “DIRECTIVE 1999/93/EC OF THE 
EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 Deeemher 1999 
on a Community framework for eleetronie signatures”. Further on an example 
of a German payment eard usahle as SSCD is presented whieh will he evalu- 
ated at the end of the year. 



1 Introduction 

One main issue of standardisation work for smart cards is the interoperability of smart 
card applications. This issue especially applies for electronic signature applications on 
smart cards: 

An electronic signature of one user, performed inside a smart card, should be 
verifiable by another user. 

A smart card with signature application should be accepted by different environ- 
ments, in the user’s home environment, in the office and /or in a public environ- 
ment (e.g. hotel, airport). 

National specifications are already in use which describe signature formats and 
smart card interfaces ( e.g. see[l] ). 

Another important issue of standardisation work has legislative importance: 

The quality of signatures should be comparable, because verifier as well as signer 
have to rely on their trustworthiness. 

Our paper describes related European standardisation activities and presents a 
smart card application in the payment field. 

The EU standardisation activities do not focus on electronic signatures on smart 
cards but describe requirements for advanced electronic signatures on product neu- 
tral tokens: Secure Signature Creation Devices. 
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According to the EU Directive [3] Secure Signature Creation Devices (SSCD) are 
able to store private signature keys of a card holder without delivering the key to the 
outside world. Therefore the calculation of the signature algorithm as well as its stor- 
age is performed inside the SSCD. 




Fig. 1. Structure of a SSCD according to [4] 



An advanced electronic signature is a high quality electronic signature, the exact 
definition is presented in the next chapter. 

In the CEN/ISSS Workshop on Electronic Signatures (WS/E-Sign), an initiative 
founded by European standardisation bodies CEN, CENELEC and ETSI, recent 
standardisation work for this type of signatures has been accomplished (see Fig. 1). 

Especially for smart cards two documents are relevant: 

One documents contains a protection profile and requirements for SSCDs (de- 
signed by E-SIGN WG F), the second one describes the requirements for the envi- 
ronment and the signature creation application (SCA (designed by E-Sign WG 
Gl) [5]. 

The German Geldkarte with operating system SECCOS (Secure Chip Card Oper- 
ating System) is an example of a smart card which has been influenced by the Ger- 
man and European standardisation work and will be evaluated according the related 
generic security target specified for smart cards [8] ( level : ITSEC E4 ) by G&D at 
the end of the year. 
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Fig. 2. Overview of Workgroups 




Fig.3. Hierarchies of the Security Target for SECCOS 
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2 EU Directive and Respective E-Sign Requirements 

According to the EU Directive an advanced electronic signature means an electronic 
signature which meets the following requirements: 

(a) it is uniquely linked to the signatory; 

(b) it is capable of identifying the signatory; 

(c) it is created using means that the signatory can maintain under his sole control; 
and 

(d) it is linked to the data to which it relates in such a manner that any subsequent 
change of the data is detectable. 

Following Annex III, 1: Secure signature-creation devices must, by appropriate 
technical and procedural means, ensure at the least that: 

(a-1) the signature-creation-data used for signature generation can practically occur 
only once, 

(a-2) secrecy of the signature-creation-data is reasonably assured; 

(b-1) the signature-creation-data used for signature generation cannot, with reason- 
able assurance, be derived 

(b-2) the signature is protected against forgery using currently available technology; 
(c) the signature-creation-data used for signature generation can be reliably pro- 
tected by the legitimate signatory against the use of others. 

The E-Sign Group F mapped these requirements into Protection Profiles following 
EAL 4 res. EAL 4+. The Article 9 committee will decide which profile will be refer- 
enced by the EU as appropriate. 

According to the EU Directive the following requirements are to be fulfilled for the 
environment: 

• data used for signature creation correspond to the data displayed to the signatory 
(comp. Annexes III 2, IV a) 

• signature creation is an act of volition of the signatory (comp. Article 5.1) 

The Directive does not cover the IT security requirements for the entire system en- 
vironment. 

The E-Sign group G1 defined requirements for the Environment of the SSCD and 
the interfaces between application and SSCD enhancing these basic requirements. 

Both documents are an important input for the development of smart card appli- 
cations following the requirements of the EU Directive. 

2.1 Signature Application on the German Geldkarte (SECCOS) 

The signature application on the SECCOS Geldkarte is designed according to the 
DIN Vornorm [ 1 ] . 

The SECCOS Smart Card operating system [14] is recently published together with 
a signature application [15]. Its design is oriented on the ISO/IEC 7816 series for 
smart cards. Especially the cryptographic command set is based on ISO/IEC 7816-8, 
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following the DIN Vornorm. The access conditions are specified according to 
ISO/IEC 7816-9. 



The G1 specification [5] distinguishes 2 different types of environments - a private 
or office environment which is controlled by the signer and a public environment 
controlled by a service provider (see. Fig. 4). In case of a public environment the 
protection of the interaction sequences may be performed by means of a trusted chan- 
nel in the public environment. There is no special technique mentioned to achieve this 
trusted path. The G1 specification suggests to replace the trusted path by organisatoric 
means, if the environment is trusted, e.g. in a private environment. 
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Fig. 5. Interaction sequences between Signature Creation Application (SCA) and SSCD ac- 
cording to [5] 

In agreement with this specification the SECCOS Signature Application supports 
two different security environment (SE) settings for use with private IFDs (SEI) and 
public IFDs(SE2). 

This may be demonstrated by the referenced example in the introduction: The 
electronic signature generation may be performed in a private environment (at home 
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or at the office under the control of the user, ’private IFD’) or public environment (e.g. 
at an airport, ’public IFD’). 

According to [15] based on [1] the card, may be used in these two different sce- 
narios. In case of the public environment the interaction between terminal and card is 
protected by mutual device authentication with secure messaging. 

Thereby, for the purpose of interoperability, a mutual device authentication proto- 
col is specified for different mechanisms as RSA, DSA and Elliptic Curves. Hereby 
the algorithm, implemented on the card is indicated by a corresponding certificate 
and is sent to the terminal for the purpose that this algorithm is to be used by the 
terminal as well. 




Fig. 6. Interaction sequences between card and terminal used in a private environment or 
public environment according to [1]. The same interaction sequences are realised within 
SECCOS 
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The mutual authentication method with key exchange also used in [15] fulfils the 
requirements of a trusted path between SSCD and the Secure Application environ- 
ment (SCA) (see Fig. 5). The sequences shown in Fig. 5 are realised using ISO com- 
mands exclusively [9], [10], [11]. 

The comparison between Fig. 4 and 5 exhibits, that the signature application on the 
card exactly represents an example of a SSCD according to [4] together with [5]. 

The key generation process for SECCOS follows as well DIN V6629I as one pos- 
sible solution of [4]. 

The key is generated in the card, the public key is transported by a trusted path to 
the Certifcate Service Provider (CSP) using Secure Messaging functions on the card. 

Electronic signatures can only be accepted if availability and quality is guaranteed. 
This may be done, if standards providing interoperability as well as quality are used 
for the design of SSCDs . Smart cards are a suitable tool to achieve both. 

Moreover, special smart card oriented protection profiles could be designed which 
base on the "token neutral" protection profile defined in [4]. Thereby the generic secu- 
rity target of [8] defined for IT SEC could be "mapped " to the internationally more 
accepted Common Criteria. Perhaps this task could be achieved in EUROSMART or 
related working groups. 
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Abstract. The Java Card Specification specifies a framework suitable for 
most tasks that interface with ISO-7816 protocols. However, this framework 
limits Java Card applets to only handling tasks that are supported by this pro- 
tocol. Tasks such as physical security using the standard Wiegand protocol, 
cards which test ISO-7816 card readers by pushing the limits of the protocol, 
and applications that depend on interfacing to different communication 
mechanisms, such as full duplex serial, USB, TCP/IP, or Bluetooth are 
among the many applications that cannot be handled within the Java Card 
Framework. In this paper we describe an approach that maintains backwards 
compatibility with the current Java Card framework, while enabling applica- 
tions a means to escape from some of the constraints of the framework when 
necessary. 

1 Introduction 

The Java Card Specification [1] presents an architecture for interoperable Java Cards. 
The specification consists of three parts. The Java Card Virtual Machine Specification 
outlines the characteristics of the interpretation engine accompanied with file format 
layouts for execution and interfaces. The Java Card Runtime Environment (JCRE) 
Specification describes the features of the card runtime such as communications, meth- 
od sharing, transactions, installation, and invocation mechanisms of Java Card applets. 
The Java Card API specification describes the on-card API used by the Java Card applet 
programmer to write Java Card applets. 

To enforce interoperability, the JCRE lays out certain firm rules to describe mntime be- 
haviour. This necessarily limits the kinds of applets that can be run within this frame- 
work. Furthermore, there is no way specified to escape the framework constraints when 
necessary to do so to implement specific applications, thus rendering those applications 
unimplementable with the current Java Cards. 

In this paper, applet always implies a card application, and often will be used without 
qualification for brevity. 
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2 Java Card Runtime Environment 



The Java Card assumes that the underlying application level protocol between an on- 
card applet and the host application is performed by exchanging data packets known as 
APDUs (Application Protocol Data Units). This protocol for communication between 
a smart card and a host application is specified in ISO 7816-4 [2] and comprises two 
primary structures, one to send commands to the card (C-APDU) and another to send a 
response back from the card (R-APDU). 



a host 
application 



command 

APDU 

response 

APDU 



command 
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Figure 1* Applet Communication with the JCRE 



Data sent to the card is first received by the JCRE. As shown in Figure 1, the JCRE 
routes the APDUs targeted to the card to the appropriate applet [3]. Hence, the JCRE 
assumes a particular stmcture for the incoming data to parse it appropriately. When the 
host application wants to select an applet to mn, it sends an APDU that specifies the SE- 
LECT command and the AID of the requested applet. The JCRE searches its internal 
table to find the AID that matches the one specified in the APDU and if found, selects 
the corresponding applet to run. All subsequent APDUs are forwarded to the selected 
applet until a new applet is selected. Access to the contents of the APDU are made avail- 
able via an on card API as shown in Figure 2. 




Figure 2* Typical ISO-7816 Communication Framework 
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The framework contains a set of communication methods needed for handling the ISO 
7816-4 protocol. Applets can access high level functions that handle data exchange at a 
buffer level, with underlying protocol details handled automatically. 

3 Motivating Applications 

Although the JCRE framework provides high level services that ease development of 
applications that utilize ISO-7816 protocol, it presumes interaction with a host that also 
uses a framework based on ISO-7816 protocol, and that the host provides the particular 
commands the JCRE requires (such as an AID-based select command). However, some 
host systems do not meet this requirement, and therefore applets interacting with such 
host systems are unimplementable on current Java Cards. Note that these examples are 
intended to illustrate some of the issues, and many more applications are affected by this 
limitation. 

3*1 Compatibility with Legacy Smart Card Terminals 

The current JCRE framework depends upon receiving APDUs which are understood by 
the JCRE, since all communications are first received by the JCRE. The JCRE then de- 
termines which applet will receive the APDU, if any. However, many legacy terminals 
do not provide APDUs which are recognized by the JCRE framework, and therefore 
will not be passed on to any applet. Such terminals include vending machines, parking 
meters, ticket dispensers, and banking terminals. It is not practical to change the termi- 
nals, which are already in the field. Yet it is impossible to introduce Java Cards into 
such an environment unless they can handle these legacy terminals, and to handle these 
terminals, the applications must bypass the framework. 

3*2 Compatibility with Physical Access Protocols 

As part of a campus solution, many times a smart card is desired to handle physical ac- 
cess issues such as building or room entry, along with other applets which are easily 
support by Java Card. The physical access protocols are often already determined by an 
installed system. A potential customer would be motivated to replace magnetic stripe 
entry terminals with smart card terminals so that the same card could be used for build- 
ing entry as well as information technology purposes, but would probably not be willing 
to replace their entire security system. 

By far the most popular physical security protocol is the Wiegand protocol. This proto- 
col is generally used by all of the remote terminals and sensors to report information to 
the security system. Therefore, any smart card that would interact with this system must 
understand this protocol. It is not hard to write a protocol handler for Wiegand protocol; 
however, the current Java Card framework could not execute such a protocol handler. 
Again, the problem is that the JCRE must first understand the protocol, and there is no 
provision for bypassing the JCRE framework. 
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3*3 Smart Card Reader or Terminal Testing 

To test smart card acceptance devices, such as readers and terminals it is desirable to 
create several kinds of test smart cards which stress the limits of the ISO-7816 protocol. 
The test cards ensure that the readers are fully behaving according to ISO-7816 speci- 
fications, by presenting test cases which are at the limits of the protocol, and making 
sure that the reader still performs correctly. One such example are the test cards for PC/ 
SC reader compliance testing. 

Because the JCRE controls the interface to the reader, it is not possible to present test 
cases with unusual timing, intentionally induced protocol errors, legal but unusual pro- 
tocol choices, and many other test cases. 

3*4 High Performance Communication Protocols 

It is clear that the current half-duplex protocol currently standardized by ISO-7816 must 
continue to be supported for legacy terminals and applications, but it will be supple- 
mented with high performance protocols such as USB, TCP/IP, full duplex serial, and 
Bluetooth, to name a few [5]. The current Java Card framework is ill-prepared for these 
protocol additions. USB cards are already a reality; current USB smart cards tunnel 
ISO-7816 protocol within USB to maintain legacy interfaces as required by Java Card. 
But native USB support offers much more features and performance, and Java Cards 
must support this possibility to be competitive with non-Java smart cards. 

3*5 Non-communication Problems 

There are other scenarios besides communication that require alternate frameworks. 
Other systemic choices made by the JCRE may need to be overridden for certain appli- 
cations. 

For example, in order to preserve the integrity of data on the card the JCRE requires 
field updates to be atomic. This places a burden on some applications that do not require 
such data integrity. Such applications could explicitly rely on Java Card's transaction 
mechanism when data integrity is required. An alternate framework could relax this re- 
quirement allowing higher performance applications. 

4 Attempted Solutions 

A couple of solutions to work around the protocol limitations of the ISO 7816-4 frame- 
work have been attempted. However, each solution had some specific drawbacks. 

4*1 Java Card 1*0 

An early implementation of Java Card [4] provided byte-level APIs from the framework 
to the card applications. This allowed the application to read or write bytes from the se- 
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rial port as desired. It did not presume an ISO-7816 command structure; instead, the 
card application was responsible for parsing the incoming bytes. 

While flexible enough to handle many kinds of serial frameworks, ISO-7816 or other- 
wise, this approach has one major drawback: any flaw in an applet could potentially 
make the card unusable if that applet were set to mn by default. Unfortunately, handling 
protocols other than ISO-7816 absolutely required having the applet that handled this 
protocol selected by default. 

Additionally, the applet entry point for Java Card 1.0 was the static main method which 
made the applet feel more Java like and made off-card simulation more straightforward. 

4*2 Adding an Entry Point Method to JC2*1 

With the advent of Java Card 2.1 and binary interoperability, scaling the Java Card 1.0 
style solution was an obvious candidate. However, adding a 'static' entry point method 
(such as main) involves changes to the standard Java Card converter and/or addition of 
a custom component to indicate the new entry point method. This requires additional 
standardization of export files for binary interoperability and complicates CAP file 
parsing to determine the new entry method. 

5 Framework-based Solution 

The solution proposed in this paper is to permit alternative frameworks to be loaded and 
selected by the JCRE to handle applications that cannot be handled under the JCRE 
framework. An alternative framework could provide new communication interfaces to 
allow an applet the flexibility needed for certain kinds of applications, while still allow- 
ing backward compatibility for current applications that depend on the JCRE frame- 
work. 

The proposed solution follows a fairly simple chain of logic: 

1. Some applets must be directly involved in the low level aspects of the communi- 
cations in order to handle special communication protocols. It is not enough to 
pass a communications buffer to the applet; indeed, it may be impossible to es- 
tablish communications unless the applet intervenes to handle the communica- 
tions using a communications protocol other than ISO-7816. 

2. Backward compatibility is based on detecting an ISO-7816 style communication 
versus a different communications protocol. Knowing when a packet is ISO-7816 
is straightforward; ISO-7816 is unique in that it sends exactly 5 bytes of data and 
waits for an acknowledgement. But even some ISO-7816 packets may be intend- 
ed for handling within the new framework, particularly packets from certain leg- 
acy terminals that use a command structure that is not compatible with Java Card 
2 . 1 . 

3. If a Java Card 2.1 ISO-7816 packet is detected, it can be routed to the JCRE 
framework to ensure backward compatibility 
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Note that this shows how a new framework could be backward compatible with Java 
Card 2.1. However, it is up to the implementer of a new framework to ensure that this 
compatibility is achieved, by routing appropriate packets (i.e. Java Card 2.1 packets) to 
the JCRE. In some cases, the new framework might be fundamentally incompatible 
with conventional ISO-7816 types of terminals. For example, a framework intended for 
use with a different kind of terminal might not be able to even provide a legacy ATR 
without interfering with the protocol of the new terminal. 

5*1 Specifying and Loading a New Framework 

A new framework is specified by writing an applet much like a conventional applet, ex- 
cept that it implements different APIs as needed, such as those needed to handle a dif- 
ferent communications protocol. When such APIs need low level access to the hard- 
ware, the APIs may be implemented using a combination of native code to provide low 
level functionality, with Java code exposing this functionality to applications. 

For example, a smart card application that needed to control the exact timing of when 
serial bytes are sent might need an API with a sendBytes (buffer, length) 
method, which immediately transmits the specified bytes of data on the serial port using 
RS-232 protocol. A smart card application intended to handle Wiegand protocol would 
need an even lower level protocol, where the exact state of the serial line is controlled 
by the application at all time. Such an application might need an API with a set Se- 
rial (state) method, which immediately sets the state of the serial line to 0 or 1. 
An API that provided precise timing could also be useful in either application, such as 
a wait ( t ime ) method, which waits a specified number of milliseconds. Using these 
two methods, an application could precisely control the smart card output to handle pro- 
tocols other than RS-232. 

The native parts of the APIs must be loaded into the card in a card specific manner. The 
Java part of the new framework can be loaded in much the same way as a conventional 
applet. A flag in the CAP file header could indicate that this file is a framework applet, 
rather than a conventional applet, so it could be triggered accordingly. Appropriate se- 
curity measures would need to be taken to authenticate and to authorize the alternative 
framework, since an alternative framework could impose a security risk, depending 
upon the low level APIs exposed. 

5*2 Selecting a New Framework 

Once a new framework has been successfully loaded, it can be specified as the default 
framework in the same manner that the JCRE currently uses to specify the application 
that is selected by default After the selection is made, the new framework will gain con- 
trol after the next reset before the answer to reset is made. In fact, it is the responsibility 
of the new framework to provide an answer to reset, if one is required for the current 
environment. 
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A standard entry point is needed for new frameworks. The applet class could be extend- 
ed to add a new entry point method, in much the same manner as the process- 
Toolkit entry point method was added for the GSM 0319 Java Card API [6]. This 
avoids the problems associated with a static entry point as discussed in section 4.2. 

5*3 Deselecting a New Framework 

When a new framework is running, the new framework can provide mechanisms to 
temporarily or permanently deselect the new framework and return control to the JCRE. 
Note that it is up to the framework developer to provide these mechanisms. 

To avoid the problem of card lockup discussed with regard to historical solutions, a 
hardware means must be provided to return control of the card to the JCRE. Thus even 
if a new framework is loaded that intentionally or inadvertently is unable to return con- 
trol to the JCRE, this hardware means can be used to recover the card. This hardware 
function could involve some special manipulation of the reset line, which is detected 
during card start-up, and resets the card to the JCRE framework. This is not intended to 
be an end user function, and should not be able to be accidentally triggered by a user. 
This mechanism is primarily intended for developers, to keep them from locking cards 
while debugging new frameworks, and for issuers of cards with new frameworks, who 
need to update or replace the new frameworks. 

It is anticipated that many new frameworks will provide Java Card 2.1 backward com- 
patibility. In this case, the new framework temporarily deselects itself and invokes the 
JCRE framework, which handles the legacy application. This could be triggered by de- 
tection of a ISO-7816 protocol command by the unique characteristics of the ISO-7816 
header. Or it could be a user command in the new framework which temporarily selects 
the JCRE framework. 

Permanently deselecting the new framework could be accomplished by temporarily 
deselecting the new framework, and then using a JCRE command to specify a different 
default framework. Or the new framework itself could implement a command which 
permanently deselects the framework. 

6 Applications 

Two applications are presented which illustrate the use of alternative frameworks. The 
first application shows how even when an ISO-7816 host framework is in use, the JCRE 
can be too constraining. In this case, specific timing of ISO-7816 commands is need to 
test compliance with PC/SC requirements. The second application details an extreme 
example of handling a framework that is not even compatible at the serial level. 

6*1 PC/SC Reader Compliance Test Cards 

In order to test whether a smart card reader was fully compliant with PC/SC specifica- 
tions [8], it was not enough to just perform a functional test of commands. The PS/SC 
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specifications called for specific timing requirements which had to be tested. In order 
to test this timing, commands needed to be sent from the card to the reader at minimum 
and maximum timing, to ensure that the reader works at both ends of the timing speci- 
fication. In addition, the ATR was slowed down so that bytes were sent at the worst case 
timing specified, and some tests involved sending the ISO-78 16 reset work waiting time 
command at maximum allowable intervals to ensure that the reader does not time out. 

Test cards for PC/SC reader compliance were created using vintage Cyberflex cards 
based on the Java Card 1.0 API [4]. This framework allowed the precise timing of bytes 
sent to and from the reader to be controlled. In effect, the Java Card 1.0 framework was 
just a pass through, which allowed the application to send bytes directly to the RS-232 
controller. This is illustrated in Figure 3. 




Figure 3* Java Card 1.0 Pass Through Framework 



Note that this card potentially suffered from the problem that any applet selected as de- 
fault could potentially lock the card. Therefore, code was added to test for a special 
command that would reset the default framework, as illustrated in Figure 4. This code 
was positioned so that it was the first code that executed upon the receipt of any com- 
mand, in order to minimize the chance that code executing prior to this segment could 
lock the card. But there was still risk that an earlier piece of code could permanently 
lock the card, which is why a hardware based mechanism such as that described in sec- 
tion 5.3 is a superior solution to the locking problem. 
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if (APDUhuffer[l] = SET_DEFAULT_FRAMEWORK) 

{ 

//Escape from PC/SC test framework 
Execute((short)0, (byte)O); 
bRetumStatus = ST* SUCCESS; 

} 

Figure 4* Escaping to the Default Framework. 

A common requirement of the test suite is that the precise timing of the bytes to the se- 
rial port had to be controlled to fully test the reader timing. One such test is illustrated 
in Figure 5. 

The test in Figure 5 stresses the timeout ability of the reader, by delaying the response 
for an extended length of time. An internal timing loop delays the response by almost 7 
seconds, the maximum time in the PC/SC specification, and then sends a single byte re- 
questing additional time. This is repeated for s Length times, which is specified by the 
host in the command, then the response is finally sent. Ideally, a framework for this pur- 
pose would provide a card independent delay function, rather than depend upon a tim- 
ing loop in the applet tuned to the specific timing of the card being used. 



if (APDUbuffer[l] = TEST_RESTART_TIME) 

{ 

// Reuse ackByte buffer to send the work waiting time byte 
ackByte[0] ^ (byte)0x60; 

for (sTemp ^ (short)O; sTemp < sEength; sTemp++) 

{ 

for (delay ^ (short)O; delay < (short) 160; delay++); // 23 loops per 0*ls 
sendB ytes(ackB yte, (byte) 0x01 ) ; 

} 

ackB yte [0] ^ pbuffer [ 1 ] ; 
sendB ytes(ackB y te, ACK_SIZE) ; 

for (bTemp = (byte)O; bTemp < (byte)sEength; bTemp++) 

{ 

dbuffer[bTemp] ^ bTemp; 

} 

bRetumStatus ^ sendB ytes(dbuffer, (by te)sEength); 

} 

Figure 5* Controlling Precise Timing of Serial Bytes 



6*2 Wiegand Protocol 

Wiegand protocol [7] is a standard protocol used for certain classes of devices, partic- 
ularly those associated with physical security, such as building entry. Rather than trans- 
mit data at a precisely described rate, as in the case of RS-232, it is a self clocking pro- 
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tocol, which intermingles the clock and data signal on a single serial line. Support of 
such a protocol clearly requires very low level serial control. 

Figure 6 illustrates how a framework specifically designed to handle the Wiegand pro- 
tocol could potentially hide the complexity of the serial modulation by providing appli- 
cation APIs at a very high level, with methods such as authenticate or sendl- 
dentity. Alternatively, the framework could provide simple byte array transfer 
mechanisms, leaving it up to the application to determine the exact content of the mes- 
sages, similar to what was provided in the Java Card 1.0 API. In either case, the frame- 
work must understand and provide the precise timing required for the Wiegand proto- 
col. 




Figure 6* Hypothetical Wiegand Card Framework 



Another option is a framework which provides very low level serial control to the applet 
itself. Such a framework would enable applets to handle Wiegand protocol, as well as 
other low level protocols such as Manchester (the level 0 protocol most often used for 
Ethernet traffic). 

To use this framework, the applet must control the precise timing of the edges of the 
serial protocol, so it is imperative that such a framework also include card independent 
timing functions. Such a framework is illustrated in Figure 7. 

The framework illustrated in Figure 7 provides two methods to assist in data transmis- 
sion: a method to set the serial port to the desired logical value, and a method used to 
provide precise timing. (It is presumed that similar methods are provided for reading 
from the serial port as well.) The applet modulates the serial port by setting it to alter- 
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nate logical values, separated by precise time delays. Thus a waveform of arbitrary 
characteristics can be created and transmitted from the card to the host. Although such 
a framework is clearly very flexible, it is also very processor intensive, and realistically 
could not be expected to handle very fast data transmission without low level support. 
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Figure 7* Low Level Control of Precise Serial Modulation 



7 Conclusion 

We have described a problem that prevents certain kinds of applications from being ad- 
dressed by current Java Cards. After considering historical solutions, we present a so- 
lution that is compatible with existing Java Cards. A flexible invocation mechanism 
will enable diverse host frameworks to be support, enabling a wider range of Java Card 
based solutions. 
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Abstract. A processor can leak information by different ways [1], elec- 
tromagnetic radiations could be one of them. This idea, was first intro- 
duced by Kocher, with timing and power measurements. Here we devel- 
oped the continuation of his ideas by measuring the field radiated by the 
processor. Therefore we show that the electromagnetic attack obtains at 
least the same result as power consumption and consequently must be 
carefuly taken into account. Finally we enumerate countermeasures to 
be implemented. 



Keywords: electromagnetic and power analysis, tamper resistance, SEMA, 
DEMA, SPA, DPA, smartcard. 

1 Introduction 

The measurement of the consumption of a cryptographic processor (smartcard) 
provides data on its activities. Handling of a bit with 1 and a bit with 0 involves 
different energy, so the electromagnetic field can be another vector of informa- 
tion. Any movement of electric charges is accompanied by an electromagnetic 
field. The currents going through a processor can characterize it according to its 
spectral signature. 

This idea is a generalization of Kocher’s idea presented in 1996. His idea laid 
the foundations of the power analysis. Actually power analysis includes Simple 
Power Analysis (SPA) and Differential Power Analysis (DPA) [2,3]. However the 
electromagnetic analysis wants to be more general. The Timing attack devel- 
oped by Kocher and its practical implementation by Koeune, are limited in the 
analysis to mono-dimensional data processing. In the same way the DPA attacks 
or second order DPA use a two-dimensional matrix to visualize the correlation 
during the treatment [4]. The results from the Electromagnetic Analysis can be 
treated as the previous ones, but they also hold a three-dimensional information 
linked to the volume. 
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Smart cards are particularly concerned [5] . They are protected against many 
non intrusive attacks but they cannot detect a listening material. Moreover, they 
emit a lot of information because memory accesses are frequent. The dimensions 
of the chip are directly linked to the emissions of all kind, and a lot of noises are 
generated by calculations and processor’s actions. 

For example, the Haming weight can be deducted during the loading time 
of the data bus. Each ” 0 ” implies the use of a specific quantity of energy, it 
is then possible to calculate the number of ” 1 ” in the data and to deduce the 
weight. SPA can allow such a measurement, and so does EM A. 




Eig 1 : Eew rounds of a DES execution. 

In a synchronous processor, the modifications finked to the evolution of the 
clock characterize the system [6]. The transfers on the bus have a consumption 
proportional to the number of bits which change between two cycles. So the 
electromagnetic analysis is strongly dependent on the architecture of the chip, 
and the knowledge of the internal circuitry of the processor facilitates the work. 



2 Context 



Eor a few years the electromagnetic radiation of the electric devices has been 
taken into account. The standards for electromagnetic radiation are present in 
order to at least allow the peaceful coexistence of various devices at the same 
place. 

All the electronic devices containing electronic components are sensitive to 
outside disturbances [7]. However they are themselves disturbing elements in 
some cases. Thus an office computer can interferer with a radio receiver. We 
decided to base on this idea to investigate the study of the electromagnetic field 
emitted by processors during their work. 

It appears that this radiation is directly connected to the current consump- 
tion of the processor. The electromagnetic field lets informations on the activities 
of the chip flee. The spectral signature is architecture dependant. However some 
behaviors are identical from a processor to another. Eor example an access mem- 
ory that activates the load pump results in a specific peak in the electromagnetic 
spectrum and is directly finked to the control of the oscillator. 
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3 Principles 

The principle is relatively simple. Indeed we placed a sensor sensitive to the 
electromagnetic field near of the processor. Such a sensor must be placed under 
the smart card, in the very close field . This device is a simple fiat coil, so the 
variations of the electromagnetic field induce a current at the bounds. This cur- 
rent betrays directly the field radiated by the chip. 




Fig 2 : The false reader with 2 coils. 



The electromagnetic field can be decomposed in two primary components : an 
electric field and a magnetic one. The electric field fails for low frequency (less 
than 10 MHz) but carries different informations than the magnetic one. From 10 
MHz to 80 MHz the magnetic component is not filtered by the bondings wires. 
Of course the current influences the magnetic part. 

3.1 How does it work ? 

Microcontrolors actually used in the cards are synchronous. Consequently it 
implies that the internal operations are cadenced on internal clocks [8]. So their 
spectral signature contains two kinds of components. The narrow bands are 
directly linked to a periodic process and the signals with broad band are due to 
an asynchronous or random activity. 

This first kind of working is the essential cause of radiations. Because an 
asynchronous activity has a lower level of emission. The difference of level is 
around 30 decibels. In the processor the clock provides a frequency of operation 
based on a wave of fixed frequency, few submultiples of this frequency are used. 
As the signals are trapezoidals, their spectrum contains many harmonics of the 
central frequency. 
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3.2 The Faraday cage 



In order to facilitate the attenuation in terms of noise reduction, we built a 
Faraday cage with 5 layers, therefore we could carry out the measurements in a 
favorable environment. Roughtly, we used copper to stop the electric component 
of the field, and mu-metal to strongly reduce the other orthogonal component. 
Actually for using EM A the chip must not be isolated from its noisy environment. 



3.3 The measurement chain 



The system, set up to acquire information and digitalize the electromagnetic 
field emitted, is very simple. In the case of a smartcard, a false card is inserted 
in the reader as a real one would be. This copy of a card (with the contacts at 
the same place) can brings out the control signals. So they were transmitted to 
our reader towards a traditional smartcard connector. Of course the card under 
measure is placed in the second reader which contains the fiat coils. Under the 
connector with contacts for the real card, three coils are present. Two of them are 
3 millemeters under the micromodule and are positioned as a ISO and AFNOR, 
and the largest one is in central position. In this manner the radiation emitted 
by the chip must cross one of the three coils. The total diameters of the coils 
do not exceed 2 centimeters. There is a connector on the side of the reader to 
connect a spectrum analyser or an oscilloscope. Provided with this equipment, 
a simple measure with the spectrum analyzer makes it possible to perceive an 
order of magnitude of the field radiated by the chip. 



4 Actual state of the work 



The work shows that the coil must be non adaptated. Global results are better 
if the quality factor of the coil is poor. It allows to measure the global field. 

EMA has been tested on a PC processor, it works perfectly, the electromag- 
netic spectrum is just wider. As a natural spectrum stops at 80 MHz because of 
the bondings wire, a Pentium’s spectrum is higher than 100 MHz. The radiation 
diagram of the chip is particular and specific for each processor. We are actually 
working on a motorized table, to move the sensor above the chip. The main idea 
is to use stepper engines to control the screws, so we will set the position of the 
sensor with a micrometric precision. 
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Fig 3 : Two 3D signatures of the same smartcard processor. 

Thus the utility of the EMA analsysis is elsewhere it resides in sent on the 
power wires and poorly radiated in the close field. 



5 Optimisations 



Sensors 



Several separate sensors were tested. Indeed a differential measurement estab- 
lished by covering of the measured zones provides good average results. Tech- 
niques of signal processing allows reduction of the noise and bring EMA closer 
to a differential measurement. All the treatments for DPA [9] are possible with 
EMA since this analysis includes at least the same information. 
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Fig 5 : A 40 micrometers sensor and three view of the same EM signature. 
The power rails are very easy to distinguish. 

In the case of a javacard, a simple applet can make it possible to maximize 
the few field radiated in cases. Indeed, while making periodic instructions or 
actions (memory access, I/O), we could manage to reveal particular electromag- 
netic signatures. 

6 CounterMeasures 

If the countermeasures are purely hard, they must be mixed with the circuit. 
Because if the two spectral signatures are too separate on the chip, it is possible 
to isolate one of them. 

Noise addition can be an elegant way for disturbing EMA. If the attacker can- 
not build a dictionary for each instruction used in the processor, it can become 
very hard to reverse all its codes. 
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Countermeasures to strongly slow down or stop the electromagnetic analysis 
are multiples they can be considered under several angles: the designer can try 
to block the information leakage, he can reduce it to a non measurable form, he 
can manage to change the possibilities of correlation, or can quite simply modify 
the architecture. These protection measures should not preferably installation 
to the detriment of consumption [10]. 



6.1 Reduction of the electromagnetic field 

The first of commonplace countermeasure consists in using the metal levels that 
build the chip, in order to reduce the radiated field. Moreover, the metals used 
in processors in the upper layers are either Aluminium or Copper. Such metals 
are not known to be excellent ferromagnetic metals. Their presence is enough 
to strongly reduce part of the electromagnetic field but does not stop its two 
components. Information available not being the same one for the electric field 
and the magnetic field if only one of the two components and decreased, it can 
always have significant losses of information. It is also important to note that the 
standardized thickness of the smartcards prevents from the quantity of plastic 
coating the processor. So it is not possible to reduce the radiation using strong 
metal plates. 



6.2 The Faraday cage 

A simple way to block the electromagnetic field radiated by the card seems 
to be to imprison it in a Faraday cage. The construction of a Faraday cage 
around the processor concerns a non commonplace exercise. However the card 
has connection requirements for the external contacts of the micromodule, so the 
Faraday screen cage could not be perfect. Such an operation is realizable, but it is 
necessary whereas each hole bores in the shielding of the cage is accompanied by 
a guide of wave having a length eight times higher than its diameter. It is quite 
obvious that such a realization is conceivable but requires deep modifications 
of the manufacturing process. Moreover the existence of such a cage will not 
prevent the attackers from trying to bore it or to introduce a reason to leak. 



6.3 Design for very low consumption 

One of the important directions [II] in current research in micro-electronics 
relates to the reduction of consumption. The techniques used are multiple, one 
of them for example uses the silicon installation on insulator. SOI thus allows to 
decrease the current consumed by the processor [12], it thus reduces the radiated 
electromagnetic field. The use of such process would also make it possible to 
obtain in certain fields of the more interesting achievements by their computing 
power increased (smart cards without contacts, memories, ). the releases of heat 
per Joule effect will be also reduced [13]. 
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6.4 Asynchronism 

Synchronous processor are those which maximize the electromagnetic field. The 
clock allows the fiip-fiop to resynchronise the signal and of the reamplify it. The 
clock is based on a trapezoidal signal including many harmonics. This results 
ends by multiple fines in the spectrum of the electromagnetic field. It is then very 
easy to distinguish the fundamental one from the harmonics, in the same way 
the internal clocks synchronized on the principal signal are visible. An elegant 
solution with all these problems of measurement of the electromagnetic field lies 
in the use of asynchronous processors. Indeed the asynchronous processors not 
including a clock to give rhythm them [14], their electromagnetic signature is 
strongly reduced. As much the synchronous processors has fines fine and pre- 
cise in their electromagnetic signature, as much the asynchronous processors 
have signatures with very broad band with a reduction by 20 to 30 db of the 
background noise. 

6.5 Dual Line Logic 

In order to reduce the electric transitions which betray their number and their 
presence on the power fine and in the electromagnetic field near. It is possible 
to try to balance these transitions. If each transition carried out commutates 
as much current of a power towards a mass and conversely, the sum of the 
exchanged currents is null, and the local field is touched [15]. Dual fine logic 
allows such an improvement. Each wire is replaced by two wire transporting 
each one information, and both of them provide the desired state. It is quite 
obvious that there are four possibilities of coding and that a designer who really 
wants to scramble the data will commutate wire not modifying the information 
transported, it is possible if the two significant states are the opposites one of 
the other. 



6.6 New architectures 

The force of EMA lying in the principle of locality, it would be desirable to block 
this principle in order to counter this attack [16]. To block the principle of locality 
is however not commonplace thing for that requires to spread out the design of 
the macro blocks of a chip over all its surface [17]. The first problem which occurs 
is then a problem of current at exit of the doors. The wire traversing the long 
processor being on the micrometric scale, the logical doors are obliged to have 
very powerful amplifiers. It is for that that it seems more judicious to build a new 
architecture blocking the principle of locality. A distributed parallel architecture 
could indeed block locally the principle of locality, if the whole of significant 
calculations is distributed. By exposing its configuration at the request of the 
software such an architecture would damage EMA. The architecture related to 
the RAW project [18] of MIT Laboratory for Computer Science seems to be 
appropriate for such a request. The possibilities and the advantages seem very 
numerous indeed, in order to block the measurement of current the designer can 
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decide to use calculating units to this end and obliges them to calculate random 
data. Moreover the software can impose a complete reconfiguration between each 
use of the cryptographic units. The faults tolerance of such an architecture seems 
also very interesting, since calculation can be carried out in parallel in completely 
duplexed form and that only the majority result can be taken into account. 

6.7 Modifications of the chip 

The solution patented by Schlumberger which consists in separating the chip 
into half chips and to assemble them face to face to prevent the attacks intrusive 
can seem good. However in a more general way the easy ways lying in a physical 
cutting of the processor in order to block the leak or to reduce the losses, seems 
quite expensive compared to the measurement techniques at very low cost to 
collect the data. The design of a chip must integrate the concept of local field 
during its creation and the sensors for these electromagnetic field can undoubtly 
still reduce of size. Wanting to reduce the field without increasing physically the 
consumption and the currents traversing the power is not seemed a commonplace 
spot. 

7 Perspectives 

The use of preamplifiers and very low noise differential amplifiers, will make it 
possible to raise the signal level quite strongly. By using the locality principle 
proper to EMA [19], and taking in account all the problems which are referred 
to it, such as bondings wires and their own field, it appears possible to us to 
analyse the work of the processor but especially to extract the data specific to 
certain parts of the chip. 

The use of an array of sensors could allow the creation of a map of the chip. 
As this array can move around the processor, the map could be tri-dimensional. 

8 Conclusion 

Actually this attack is not better than the power consumption attack. But as 
the electomagnetic field can be observed in a local part of the processor, it seems 
to open the sensibility of new attacks. We mean that the current measurement 
must be global if the attack is non intrusive, EMA can be more precise. 

Countermeasures are purely hard against power consumption, it seems very 
difficult to defeat electromagnetic analysis, except if the circuit and its counter- 
measures are overlapped. On the opposite way, as each instruction has a specific 
electromagnetic signature, it is possible to build a dictionary and to reverse a 
part of the code. 

As the processor contains very specific or regular parts, their spectral signa- 
ture is characteristic, so if the processor has a memory or a grouped data bus, 
it is an advantage for EMA. 
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Abstract. In this article we will be concerned with a polynomial-time 
attack against the ECDSA, which computes the secret key of the ECDSA 
if a few bits of the ephemeral- key from several ECDSA-signatures are 
known. The number of needed bits per signature is 12, if one has access 
to an ideal lattice basis reduction algorithm computing the successive 
minimum of a lattice with rank n. The aforesaid bits of the ephemeral-key 
can be obtained from insecure ECDSA implementations by so called side- 
channel- attacks like Timing, Simple- Power- Analysis, Differential- Power- 
Analysis, Electromagnetic or Differential-Eault attacks. Our attack com- 
bines a recent idea of Howgrave- Graham and Smart with an old lat- 
tice attack against linear congruential pseudo-random number genera- 
tors due to Erieze, Hastad, Kannan, Lagarias und Shamir. In contrast 
to Howgrave- Graham and Smart, our approach enables the exact deter- 
mination of the number of needed (side-channel) bits and uses an easier 
lattice problem making the attack very practical. 

Keywords: Cryptanalysis, ECDSA, Lattice, Lattice basis reduction, 
LLL, side- channel- attacks, successive minimum. 



1 Introduction 

The ECDSA (Elliptic Curve Digital Signature Algorithm)^ see for, e.g., [JM], is 
a digital signature algorithm whose security is based on the discrete logarithm 
problem for elliptic curves (abbreviated as ECDLP for Elliptic Curve Discrete 
Logarithm Problem) and is derived naturally from the DSA which in turn is 
based on the El-Gamal signature algorithm. For a thorough introduction into 
the DSA and the El-Gamal signature we refer the reader to [MvOV]. 

Under slight modifications and assuming the random oracle assumption Bel- 
lare et alii [BPVY] have shown that the security of the ECDSA can be reduced 
to the ECDLP. Excluding insecure elliptic curves the ECDLP needs in general 
exponential time to be solved, see for, e.g., [BSS]. Thus, practically the ECDSA 
cannot be broken by solving the ECDLP. 
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However, it is well known that knowledge of the ephemeral- key k of the 
ECDSA breaks the system. Moreover, choosing the ephemeral-key k uniformly 
at random is as well very important, which is due to Bellare et alii [BGM]. 

This article describes a novel attack against the ECDSA, which is a combi- 
nation of classical cryptanalysis and a side-channel attack. Instead of attacking 
directly the secret key d we use lattice methods to attack the randomly cho- 
sen ki from several card signatures. Eor this purpose the attack assumes that we 
can learn through a side-channel some bits of the the aforesaid randomly chosen 
ephemeral- keys ki corresponding to the card signatures. Our attack is based on 
an idea of [HGS] and using methods from the geometry of numbers according 
to [EHK+] we can improve the attack of [HGS] substantially while also extend- 
ing their attack to the elliptic curve variant of the DSA. Eor a recent survey on 
lattice methods in cryptography we refer to [NS]. 

Gaining knowledge of some secret bits of a smart card is in insecure im- 
plementations possible by exploiting methods relying on side-channel attacks 
such like Timing, Simple-Power-Analysis, Differential-Power- Analysis, Electro- 
magnetic or Differential-Eault attacks. Eor a thorough description of these at- 
tacks we refer to [HJMS] and [GKN]. 

2 Definitions 

We now give a brief introduction into basic terms of the lattice the- 
ory and elliptic curves and refer the reader for detailed introductions 
to [Kan,Lov,BSS,Kob99,Men]. 

denotes the m-dimensional real Euclidean vector space and the 
unit vector in (•, •) the canonical scalar product in and ||'r’|| := 
for V G the Euclidean norm. A lattice L is a discrete additive subgroup of the 
with L := {y ^ | y = aibi + • • • + Cikbk, ai G Z}, 6i, . . . , 6/^ G linear 

independently over and k < m. [6i, . . . , 6/^] is called a basis of the lattice L. 
The successive minimum Xi{L) of a lattice L is the smallest positive real 
number r, such that there exists i linear independent vectors ... ^Vi G L of 
maximum length r, i.e., Xi{L) = min max^-^{i^...^^} \\vj\\. 

An elliptic curve (in affine coordinates) over a finite field IK is a set E(K) of 
points (X, Y) satisfying an equation of the form 

Y^ T a^XY T a^Y = X^ T a2X^ -t- a4.X T ug, a^ G -A, 

together with a point at infinity O. The set E{K) is an abelean group wrt. addi- 
tion +, where O is the neutral element, see for, e.g., [BSS]. The order of a point 
P G E{K) is the smallest natural number n with nP = O. The EGDLP is given 
by the following problem. Eor two given points P and Q on an elliptic curve find 
the smallest natural number d satisfying Q = dP. Eor a general elliptic curve 
the EGDLP is only known to be solvable in exponential time. 
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3 The ECDSA 

We now give a brief introduction into the ECDSA, for a thorough description 
we refer to [JM]. Moreover, for simplicity we assume in the following that we 
are using a prime field K = Fp, i.e., p is a prime greater than 2. However, our 
attacks works also fine over fields of the form ¥ 2 m. 

We consider the situation where Alice wants to send a signed message m to 
Bob. Firstly, Alice chooses her public key {E{K), P^n^Q) and as well a private 
key d G [1 : n — 1]. Here, E(K) is an elliptic curve over K and P a point of prime 
order n on the curve K with Q = dP and n \ \E{K)\. 

To sign the message m G Ai from an appropriate message space A4, Al- 
ice now chooses uniformly at random a number /c G [1 : n — 1], the so called 
ephemeral-key. Hereafter, Alice computes kP =: (xi,^i), r := xi mod n and 
as well s := + dr) mod n, where h : Ai ^ K denotes an arbitrary 

cryptographic hash-function. Alice now sends Bob the message m and the cor- 
responding signature (r, s). 

In order to verify the signature (r, s) of the message m. Bob computes with 
the public key {E{K), P^n^Q) of Alice as a first step w := s~^ mod n. Then, 
Bob computes Ui := h{m)w mod n, U 2 := rw mod n, U\P + U 2 Q =: (xo,^o) and 
V := xq mod n. Finally, to check the authenticity of the signature (r, 5 ), Bob 
checks that v = r holds. 

As already said above, the security of the ECDSA is based on the ECDLP and 
indeed under slight modifications and assuming the random oracle assumption 
([BPVY]) its security is reducible to ECDLP. Thus, excluding insecure elliptic 
curves the ECDSA cannot be broken by solving the ECDLP in theory. 

In the next section, however, we will sketch a new practical lattice attack on 
the ECDSA which tries to reconstruct the secret key d from short ephemeral-key 
fragments, i.e., by using only some bits of several keys k generated by several 
card signatures. 

4 The Attack 

We consider the scenario, where Alice’s public key is given by (E(i^), n, P, Q) 
and her secret key by d. Moreover, we assume that we have signed I messages m^, 
i = 1, . . . , / , and obtained their corresponding card signatures (r^, s^), i = 1, . . . , / . 
Now, we want to compute the ephemeral keys i = 1, . . . , / , chosen uniformly 
at random by Alice for every single signature (r^, s^), i = 1, . . . , / . After having 
computed the ephemeral keys ki^ i = 1 ,...,/, we directly can compute Alice 
secret key d. 

From the ECDSA-signature equation 

Si := k^^{h{rrii) + dri) mod n, i = 1, . . . , /, 

we get 

Siki — dri = h{rrii) mod n, i = 1, . . . , /. 
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Substituting in these I equations with the I + 1 variables i = 1, . . . , / , and d 
the variable d by r^^siki — h{mi)r^^ mod n yields the system 

Siki — ViV^^siki = —rih{mi)r^^ + h{rrii) mod n, i = 1, — 1. 

Renaming again the variables yields another system of equations 



bah + biiki = di mod n, i = 1, 1 



with only I — 1 equations and I variables ki^ ... ^k[. However, this underdeter- 
mined system has naturally no unique solution. Nevertheless, it is known that a 
unique solution exists and indeed can be computed quickly if some small fraction 
of the bits of the ki^ ... ^ki is known, see for, e.g., [FHK+]. 

Wlog. let logn the bitlength of the i = 1, If, now, the most signifi- 
cant t bits of the k{ are known, we can write the ki as 

ki = fcf ) + kf\ 

where the are all known, and < n2“* holds. Applying this partial 

knowledge about the kd^ to the aforesaid system of equations and again renaming 
the coefficients we get the following system of equations: 

aukf‘^ + auk!f^ = Ci mod n with < n2~^ . (1) 

Thus, we have obtained an under deter mined system with the variable con- 
straint \k!f‘^\ < n2~^ where t denotes the number of known most significant bits 
of the ki^. To solve this system we use the following theorem. 

Theorem 1. Let 

i 

aijXj = Ci mod p (2) 

i=i 

a system with aij^Ci G Z, i = 1, . . . , s, p prime and s < I, and 



L = 




s 

y = • • -,0,11^ +Vs+ipei H h Vg+ipei, 

i=l 



eZ 



a lattiee in satisfying ||x|| < pXf^ {L)2~^ , then there exists at most one solu- 
tion X for this system. If the Oij, Ci and p are all known for all i,j, then there 
exists an algorithm whieh eomputes for fixed I in polynomial time the solution x 
or proves that there is no solution. 

Proof. The proof of the theorem follows mainly the ideas given in [FHK+]. The 
idea is to construct from the underdetermined modular system of equations a 
system of equations with I equations and I variables over Z. Naturally, such a 
system has at most one solution. We note that the proof will explicitly construct 
the unique solution, provided that a solution exists. 
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We start with the recently presented algorithm due to Blomer [Bl], which 
computes for the given lattice L I linearly independent vectors 

e L 

with ||re^|| = Xi{L) for i = 1, Its running time is where s denotes 

the size of the lattice. Thus, for fixed / it is a polynomial-time algorithm. As the 
vectors wi, ... ,wi are linearly independent lattice vectors we know that there 
exists some integral I x (s + /) matrix M satisfying 



/wu ■■■ Wil\ 



\Wli ■■■ Wll J 



= M 



ail • • • aii\ 



• ^sl 

p • • • 0 

Vo ••• p J 



Now, multiplying both sides of the system (2) from left with this matrix M, 
we get a new modular system 



WijXj = c[ mod p, i = 1, . . . , /. 
i=i 



(3) 



Clearly, every solution x of (2) is by construction also a solution of (3). Now, 
considering an x G satisfying 



Ikll < \L), 



we get that 



i 

J=1 



<IKIMkll 

< K{L) ■ IpXt\L) 
<XiiL)-^X-\L) 

- 2 



Therefore, choosing the c' for i = 1, . . . , / such that |c'| < p/2, ensures that an 
integral solution x E of the system 



i 

i=i 



(4) 
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over Z will also be an unique solution of the system (3) satisfying \\x\\ < 
This is due to the fact that the aforesaid system (4) has at most 
one solution over Z. Consequently, our starting system (2) has at most one so- 
lution satisfying ||x|| < □ 

Now, in order to determine the unknown fraction of the ki, i.e., , we 

will apply the former theorem to the above equation system (1). However, the 
applicability of Theorem 1 requires 

\kP\<nXi{L)-^2-H-^/^. 

With the subconstraint \k^^^\ < n2~^ for the unknowns k^^^ this means that one 
needs to know 

t = logA^(L) + 1 + ilog/ 

bits of every ki. Therefore, the number t of known bits in advance only depends 
on Xi{L). Luckily, if the coefficients are chosen uniformly at random, one can 
show that with high probability 

Xi{L) < 

is satisfied, where 5 > 0 is an arbitrarily small positive constant. This will be 
shown in the following theorem whose proof combines ideas from [FHK+] with 
latest lattice research due to [Ba]. 

Theorem 2. Let n he a prime, 5 > 0 and 



L I — G I y — Zn^ T . . . T Zn/_i -h Zne^ T . . . T Znc/} 

a lattiee in , where a\ := (ai, 0, . . . , 0, a/), . . . , a/_i := (0, . . . , 0, a/_i, ai) are 
randomly ehosen in . Then, with probability > 1 — e — 0{l/n it holds 

that 

( 7T*/2 \ 

Proof. As an abbreviation we define for the basis 

H := (ai, . . . , ai-i,nei , . . . , nei) 
of the lattice L the so called span(H) as 

span(H) := {y \ y = Mai + • • • + Ma/_i + Mnei + • • • + Mne/}. 
According to Kannan [Kan] the lattice dual to the given lattice L is given by 
L* := {z G span(H) | G T : ( 2 ;, G Z}, 
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which means particularly that 



L* = {zGR^\'iyGL: {z,y) e Z} 

= {ze \ll I ( 0 , ffli) G Z, i = 1} 



and moreover also that 

nL* = {z e \ {z, ai) = 0 mod n, i = 1, . . . , / — 1}. 
Thus, we see that for a randomly chosen point z G we have 

Pr \{z. ai) = 0 mod n] = — 

n 

for every i = — 1, which in turn implies that 



Let Sr{o) := {x eW \ \\x\\ < R} the usual open sphere with radius R around 
the origin o := (0, . . . , 0) and denote by Gr{o) := |5'i?(o) D Z^| the number of Z 
lattice points within Sr{o). From the above we are now able to infer that 



Pr n nl/* = 0] = (1 — 1/n^ ^ — Gr{o)/ti^ 



holds with probabilty > 1 — Due to Walfisz [Wa] the number Gr{o) 

is for ^ 00 given by 







Thus, we see that 



Xi(nL*)>R ^ Xi(L*)>- 

n 




Choosing now 




yields for n ^ 00 that 



Gfl(o)=£n('-i)+o(n(*-D'/*), 



from which we conclude that 



n 25 
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holds with probability 1 — e 0{n If we now apply the so called trans- 

ference bound 

Ai(L*).A,(L) </ 

due to Banaszcyk [Ba], we finally get our promised result 



Xi{L) < 



I 



< e-^/i 

6 



□ 



If we yet put together all the results we have so far, we get that with 
t > y log 2 n + log 2 I + J log 2 5 + 3.06 

known bits of of the randomly chosen ki we are able to recover the rest of the ki . 
The goal is now simultaneously maximizing the probability 1 — s 
and minimizing the number t of needed bits in the ki. We simply set 5 := 0.01 
and investigate the two functions 

/i(n, /) := j log 2 n + log 2 I - j log2(0.01) + 3.06 

/2(n,0 + 



concerning local minima and maxima. However, for /2 we need to consult Wal- 
fisz [Wa] for the hidden constants in the O resulting from Gr{o). Precise deter- 
mination of these constants and searching for local minima and maxima results 
finally in a probability of 0.99 and 12 known bits of the ki if we assuming that n 
is a 160-bit prime. 

Thus, we have proved that with only 12 known bits of every i = 1, . . . , 50, 
the ECDSA can be broken in practice. We stress, that these are proven worst- 
case bounds, whereas in practical experiments we needed much less than 12 bits. 
Moreover, our attack can be extended to cover even the case when the known 
bits are somewhere located within the /c^’s. 

5 Summary 

Again, lattice methods have been used to show that a secure proven signature 
method like the ECDSA can be broken under some circumstances. This implies, 
that it is very important to protect hard- and software implementations of the 
ECDSA on smart cards very carefully against side channel attacks in order to 
avoid any information leakage of secret data to a potential attacker. 
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Abstract. If a smartcard provides security functions such as electronic 
signature creation, valuables such as electronic money and/or sensitive 
data such as medical data, then the smartcard has to verify that it is used 
by the legitimate cardholder. For this purpose, the user has usually to 
present a PIN. Since smartcards become more and more powerful, it is 
feasible to implement on-card matching algorithms allowing to perform 
a biometric user verification in the smartcard. 



1 Legal Background for Electronic Signatures 
and Signer Verification 

In 1999, the EU has published the “EU Directive 1999/93/EC of the European 
Parliament and the council of 13 December 1999 on a Community framework for 
electronic signatures [1]”. 

In this Directive, the use of “Secure Signature Creation Devices (SSCD)” for the 
creation of Qualified Electronic Signatures is described. The most important instance 
of such an SSCD is a smartcard which is able to compute an electronic signature 
using the Signature Creation Data (= signature key) of the signer. It is required, that 
the Signature Creation Data shall be protected against misuse and - further more - that 
there should be a unique link between a qualified electronic signature and the signer 
as shown in fig. 1 . 

In order to promote the use of electronic signatures, CEN Working Agreements 
(CWA) has been worked out within the context of the so-called E-Sign Workshop. 
Two documents are of special interest for smartcards: “CWA Security Requirements 
for Signature Creation Applications” [2] und ‘‘CWA Secure Signature Creation 
Devices” [3]. 

Two types of signer verification methods are possible: 

• knowledge based signer verification 

• biometric signer verification 

The first verification method requires the presentation of a Personal Identification 
Number (PIN) or password. The second verification method requires the presentation 
of a physiological or behavioural biometric feature. 

I. Attali and T. Jensen (Eds.): E-smart 2001, ENCS 2140, pp. 220-227, 2001. 
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Unique link 




Qualified 
Electronic Signature 



Unique link means technically: 

The SSCD has to verify that the legi- 
timate signer is the one who re- 
quires a signature creation. If there 
are other means for keeping the SSCD 
under the sole control of the signer, 
then they are also applicable. 



Unique link means technically: 

The Qualified Electronic signature 
can only be created by an SSCD 
with the related signature creation 
data corresponding to the signature 
verification data from a qualified 
certificate. 



Fig. 1. Linkage of a Qualified Electronic Signature to the Signer 



2 Usage of Biometrics in Electronic Signature and other 
Smartcard Applications 

The biometric industry has developed a great variety of products using different kind 
of biometrics: 

• Fingerprint 

• Face recognition 

• Voice pattern 

• Signature dynamics 

• Iris pattern 

• Hand geometry 

• key stroke 

• 

Due to the complexity of matching algorithms and their requirements with respect to 
program storage, data storage and CPU capacity, it is not yet possible to implement 
matchers for all kind of biometrics in today's smartcards. Matchers for fingerprint 
verification has been successfully implemented, matchers of other biometric methods 
will follow. In the EU study [4], more details are presented. 

In applications designed for a greater portion of the population, the usage of bio- 
metrics cannot be enforced. Biometric methods are not suitable, nor applicable to any 
signer, or more general, to a user in the following cases: 

• rejection due to personal reasons; 

• cultural incompatibility; 

• absence of the respective biometric feature; 

• insufficient characteristics of the respective biometric feature; 

• abnormal characteristics of the respective biometric feature. 
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Therefore it is always to expect, that the knowledge based user verification method 
will be available as alternative. Furthermore, even in the case a user wants biometrics, 
the PIN method will remain as back-up possibility as shown in fig. 2, since there may 
be conditions where the user cannot present the respective biometric feature in the 
required way (e.g. if your hand is broken, you cannot perform signature dynamics). 
Furthermore, it cannot be expected that all possible service systems have a respective 
biometric unit. 




Fig. 2. User verification methods and user preference 

Since an enrolled user will usually prefer to present the biometric feature, if possible, 
he might have even a greater problem to remember a PIN rarely used. A solution to 
this problem can be to store all PINs in a protected device (e.g. in the handy, in a 
palmtop or a dedicated PIN storage device), so that the user has only to remember one 
PIN. 

3 Biometric User Verification in Smartcards 

If biometric user verification is provided, then a work sharing between service system 
and smartcard takes place in the way, it is shown in fig. 3. The biometric reference 
data have to be stored in the smartcard either 

- when personalizing the smartcard using biometric reference data captured in a 
separate enrollment process before or 

- when the smartcard is delivered to the user in an authorized service center (e.g. a 
bank). 

4 Standardisation Issues 

In order to enable interoperability, standards for various topics are needed. 

4.1 Interindustry Commands for Biometric User Verification 

Interindustry commands for knowledge based user verification have been specified in 
ISO/IEC 7816-4 “Interindustry commands for interchange [5]” (VERIFY command) 
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and in ISO/IEC 7816-8 “Security related interindustry commands [6]” (commands 
CHANGE REFERENCE DATA, ENABLE/DISABLE VERIFICATION REQUIRE- 
MENT and RESET RETRY COUNTER). In ISO/IEC 7816-11 “Personal verification 
through biometric methods [7]” the usage of the VERIFY command has been exten- 
ded to support those biometric user verification methods, which work with static 
features from the viewpoint of the smartcard (e.g. fingerprint, signature dynamics[]. 
For dynamic biometric methods, which needs to retrieve a challenge from the card to 
which the user has to react on (e.g. voice recognition, if several words have been 
enrolled), the commands GET CHALLENGE and EXTERNAL AUTHENTICATE 
have been extended for biometric usage. 




Fig. 3. Work sharing between serviee system and smarteard with on-eard matehing 



4.2 Biometric Information Data Objects 

Prior to sending e.g. a VERIFY command to the smartcard, the service system must 
know whether 

- the user is enrolled and if, 

- the biometric type 

- the biometric feature (e.g. which finger is enrolled) 

- the conventions for the biometric verification data. 



^ The smartcard receives only the biometric verification data and cannot recognize whether 
these data have been produced on the basis of an action or just presentation of the respective 
biometric feature. 
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Biometric information data objects will be defined in ISO/IEC 7816-11 in compliance 
with the Common Biometric Exchange File Format [8]. 



4.3 Biometric Data 

The service system has to perform the feature extraction and the encoding of the 
biometric verification data in the way required by the smartcard. If this is not 
possible, then service system and smartcard are incompatible with respect to bio- 
metric user verification. For interoperability it is therefore mandatory, to standardize 
the biometric verification data seen at the interface. Not the algorithm itself has to be 
standardized which takes the sensor data and computes the verification data, but the 
structure and encoding of the data. The algorithm remains intellectual property. For 
fingerprints, the first standard was issued by NIST already 1993. In April 2001, a new 
standard has been issued by ANSE “Finger Minutiae Extraction and Format Standard 
for One-to-One Matching [9]”. Standards for other biometric methods will follow. 




Fig. 4. Usage of standardized and proprietary biometrie data 

The ANSI standard on Minutiae encoding is not applicable for smartcards without 
adaptation. Therefore it is expected that on the ISO level a New Work Item will be 
initiated possibly by ANSI. Biometric verification data may be split in a standardized 
part and in a proprietary part e.g. for achieving a better performance, see fig. 4. 
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4.4 Cryptographic Security Issues 



Several biometric methods uses biometric data which cannot be considered as secret, 
i.e. they use “public verification data”, e.g. fingerprints or facial data. It is obvious 
that e.g. the minutiae data cannot be simply presented to the card using the VERIFY 
command. They have to protected e.g. by a cryptographic checksum whereby the key 
used may be established in an authentication procedure with key exchange to avoid 
replay attacks (see fig. 5). 



Command/Response 


Meaning 


SELECT FILE <AID> 

► 

OK 

◄ 


Selection of the appli- 
cation with Application 
Identier (AID) 


GET DATA <Tag BIT> 
Bio. Information Template 


Retrieval of the 
Biometric Information 
Template (BIT). 


MANAGE SE <DO Key Ref> 
OK 

◄ 


Setting the CRT DST 
with the public key for 
certificate verification 


VERIFY CERTIFICATE 
<certificate> 

► 

OK 

◄ 


Verification of the 
certificate belonging 
to the biometric unit 


GET CHALLENGE 
► 

Random Number 

◄ 


Requesting a chal- 
lenge to be used 
for secure messaging 


EXTERNAL AUTHENTICATE 

<authentication related data> 

► 

authentication related data 

◄ 


External authentication 
with establishing of 
SM keys 


VERIFY <Biom. Verification 
Data, SM protected> 

► 

.1 5!^ 


User verification with 
SM protected verifica- 
tion data; response can 
also be SM protected 



Fig. 5. Example of a command sequence, where the biometric verification data are protected by 
a cryptographic checksum 

Also the new ANSI standard X9.84 [10] points out, that cryptographic security me- 
chanisms are needed in the context of biometrics. 




226 Bruno Stmif 



4.5 Testing and Evaluation 

Especially in the field of electronic signature smartcards, evaluation according to 
ITSEC or Common Criteria is required. The evaluation assurance level depends e.g. 
on the quality of the electronic signatures which shall be created by the respective 
card. If the signature creation data (i.e. the signature key) shall be protected by 
biometric user verification, then the respective biometric verification method is also 
subject of evaluation. Aspects of testing and evaluation are rather new in the field of 
on-card matching and the need of dedicated evaluation test and evaluation documents 
has to be explored. In UK a “Biometric Device Protection Profile” [9] is under de- 
velopment, which may be adapted or precised for the usage in the context of on-card 
matching. 

5 Benefits 

Biometric user verification will become an important feature especially in the context 
of electronic signature smartcards. The benefit will be not only the provision of more 
convenience for the user. A big advantage will also be, that the receiver of an 
electronically signed message can be sure that the respective message has been really 
signed by the respective cardholder, if the signer has been verified by biometrics and 
this fact has been added by the smartcard itself to the signed signature attributes in an 
unforgeable way. 



6 Outlook 

The provision of biometric user verification in smartcards is still a challenge to the 
industry, research institutes and evaluation bodies, since there are still some open 
issues as outlined with respect to implementation of the algorithm itself, crypto- 
graphic security issues and testing and evaluation. However, great efforts will be 
made to achieve quick progress. It should be mentioned, that also fingerprint sensors 
and complete fingerprint verification modules, which can be integrated in a smartcard, 
are under development. 
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Abstract. This paper describes an innovative architecture for an internet 
smartcard. We believe that a communication stack approach, in which a 
smartcard is used as an usual internet node (running well defined server and 
client applications) is the best way for adapting smartcards to internet appli- 
cations. Our experimental smartcard is organized around an XML script 
parser, which is invoked from an embedded web server. XML scripts have ac- 
cess to all embedded resources, and manage connections to remote internet 
servers. 



1 Introduction 

A communication stack approach aims at using smartcards as an usual network 
node. In this context smartcards run internet server and client applications (which 
are defined by internet RFCs). They include an Http server, every embedded resource 
is identified by an URL; they are able to exchange information with remote internet 
servers according to various protocols. Communication with embedded objects is 
performed thanks to XML messages, in order to support emerging distributed archi- 
tectures, like SOAP. 



1.1 Motivation 

Smart cards are generally recognized as the best device to insure safe data storage, 
and to process cryptographic algorithms (encryption / decryption , certification...). 
But until now, no high level interface has been specified for smart cards. The ISO 
7816 standards only define a set of low level commands (APDUs), which typically 
perform writing orders, reading orders, or cryptographic functions invocation. 

Therefore, a software component working with a smartcard must generate specif- 
ics APDUs which are needed for achieving a particular service. In order to improve 
inter-operability, some tentatives have been done to describe this translation in XML 
syntax, according to a particular grammar (SML - smartX Markup Language [17]). 



I. Attali and T. Jensen (Eds.): E-smart 2001, LNCS 2140, pp. 228-241, 2001. 
(c) Springer- Verlag Berlin Heidelberg 2001 




Programming Internet Smartcard with XML Scripts 



229 



But a dedicated SML parser (named application process) must be plugged in 
standard web browsers which don’t natively support this feature. 

For several years, there is an increasing trend to use Internet anywhere, and from 
any terminals (ubiquitous Internet). This need is increasing, due to the exponential 
growth of the net economy. Internet Protocol is the de facto standard for data ex- 
change (IP overall). In particular, web browsers are becoming a standard man ma- 
chine interface, which exchange electronic documents, using HTML or XML lan- 
guages. 

For example XML documents are made up of storage units called entities, which 
are identified by URLs and transported by HTTP protocol. Therefore a smartcard 
supporting HTTP protocol and including a web server is natively adapted to XML 
technologies. As a consequence embedded resources are identified and named by 
URIs (Unified Resource Identifier). 

INTERNET ! SMART CARD 



COMMUNICATION 




1.2 Embedded XML Parser 

An other critical issue is identification and execution of embedded procedures. More 
generally the basic problem is to interact with smartcard objects. There is a trend in 
distributed architecture (like CORBA) to exchange data between objects, according 
to non-proprietary transfer syntax like XML. 
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As an illustration the SOAP protocol, an XML based protocol, has been designed for 
information exchange in a distributed environment (like Internet network). 

It consists of three parts: an envelope that defines a framework for describing 
what is in a message and how to process it, a set of encoding rules for expressing 
instances of application-defined data types, and a convention for representing remote 
procedure calls and responses. 

We believe that an embedded XML parser, interpreting XML encoded messages 
carried in HTTP requests, is a right approach for using smartcard in distributed 
environment. Smartcard implements HTTP protocol, and its objects are invoked 
through XML messages. We shall distinguish two kinds of embedded resources 
(figure 1), 

• Various file, like HTML or XML documents, images or mobile code (APPLET, 
ASP...). 

• XML scripts, which access to all smartcard internal resources, including crypto- 
graphic functions, and may supervise connection and/or authentication procedures 
with remote internet servers. 

We expect to support protocols like, 

- HTTP [8], connection to remote internet web server. 

- LDAP [14,15], directory for smartcard management. 

- H323[9], SIP [16], authentication features in VoIP applications. 

- SSL [7,8], for eCommerce applications. 



1.3 Architecture 

In this paper we shall describe an architecture (figure 2) supporting internet applica- 
tions and XML script programming. It includes four main components, 

• A communication stack, distributed between smartcard and terminal. Thanks to 
this entity embedded applications exchange data with remote internet nodes. This 
stack is based on SmartTP protocol [5], which is the only one that supports client 
and server applications in today 8 bits smartcards. 

• A web server, which manages the HTTP protocol. All smartcard resources are 
identified by URLs. 

• An XML script parser which is the central point of our internet smartcard. It has 
access to every embedded resources and manages one or two internet sessions. 

• A file System Interface, which supervises files operations (reading, writing) and 
is in charge of all authentication procedures. 
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MD5 
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LDAP 
H323 
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Fig. 2. Software Architecture 



2 Communication Stack 

The goal of a communication stack (figure 3) is to exchange information between 
smartcard and the internet network. It is distributed between terminal and smartcard, 
because this device is quite different from a classic computer, 

First, it doesn’t include a communication board, in order to send and receive data 
from network. This resource must be located outside the smart card, in a terminal 
to which the card reader is connected. 

Second, communication protocols (ISO 7816 T=0 or T=l) are not full duplex, 
terminal sends a command and smartcard produces a response. For that reason a 
simple protocol like SLIP (serial line IP), which requires a bi-directional serial 
link, can’t work with a 7816 chip. 
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2.1 State of Art 

Several (web) server architectures have been proposed for smartcards, 

• HTTP proxy server [1] . A software running in a terminal implements an HTTP 
server and is customized for each smartcard; it translates an incoming HTTP re- 
quest as a set of APDUs which select and read an embedded smartcard file. 

• TCP server [2], a subset of TCP protocol is implemented in smartcard. A tunnel 
software running in terminal forwards TCP/IP packets encapsulated in APDUs 
to/from smartcard. 

• Protocol gateway [3], a software located in terminal translates TCP protocol in an 
other protocol transport, named SmartTP (Smart Transfer Protocol). SmartTP 
packets are sent/received to/from smartcard and carried by APDUs. 

Client features, e.g. embedded smartcard software’s exchanging data with a re- 
mote internet server, are more complex to define and design. This functionality is 
today only supported by SmartTP communication stack [5], in this case smartcard 
shares terminal TCP/IP configuration, including IP address, DNS server, gateway, 
web proxy, . . . 

We believe that protocol gateway architecture is the best choice for IPv4 network, 
because the number of addresses is limited, and mobility is not really supported. 
However a fix IPv4 address may be suitable for applications in which smartcards 
work in the same geographical IP sub-network. If mobility is required then smartcard 
must implement DHCP protocol, and internet service provider (ISP) must affect an 
IP address to each smartcard; these two constraints are not realistic with today ISP 
capabilities and smartcard computing capacities. 

IPv6 uses 128 bits addresses, which implies that their number is quite infinite; 
therefore it seems to be the future way for smartcard application naming. But be- 
cause smartcard is a mobile object the support of mobile IP will be mandatory. 



2.2 Socket 

In network, a smartcard application is located by two parameters, 

• A Network Service Access Point, NSAP, which is the network address associated 
to a smartcard. This parameter can be an IPv4 or IPv6 address in the internet 
network or a phone number in the GSM network. 

• A Transport Service Access Point, TSAP, which is the name of an embedded 
application. In TCP/IP architecture a port number (between 0 and 65535) identi- 
fies a specific application (for example the well known port value 80 is associated 
to a web server). 

We call socket, the couple NSAP:TSAP which identifies a smartcard embedded 
application. 
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2.3 Channels 

A logical channel is a session between two applications, one of them is located in a 
smartcard (SC) and the other in a remote network node (NET). It’s identified by two 
sockets, SC_NSAP:SC_TSAP and NET_NSAP:NET_TSAP. 

Typically channel #0 is affected to a session between card web server and an ex- 
ternal client (web browser ...), a second channel (#1) is available for a session with a 
remote internet server. 



2.4 Marks 

We call payloads, data which are sent and received by the terminal to/from the 
network. Payloads, which are coming from the network are stored in one or more 
reception queues, located in the terminal, in order to be sent when possible toward 
smartcard. 

Because terminal and smartcard need to exchange additional information, a header 
is added to the payload, and then these data (header + payload) are transported ac- 
cording to a 7816 protocol. Terminal and card exchange stack protocol data unit 
(SC_PDU) which are made up with a payload (network data) and a header. Concep- 
tually a SC_PDU is always sent over a smart channel. 

A header may include a channel name (SC_NSAP:SC_TSAP 
NET_NSAP:NET_TSAP) associated to its payload and other information, that we 
call marks. We manage five marks in order to exchange data over a channel, 

• BLOCK. 

- This mark is issued by a sorting terminal stack (TSS) to notify that no more 
payload will be sent until the reception of a CS_PDU addressed to this channel. 

- This mark is produced by smartcard stack (CSS) to indicate that a channel 
want to send data again. 

• READY, when no particular event is associated to a payload, CS_PDU includes a 
READY mark. 

• OPEN, this mark indicates a new channel creation. 

• CLOSE, this mark notifies a channel deletion. 

• NACK, this mark is produced by CSS in order to delete a channel and then to 
send an other CS_PDU. The terminal response is a CS_PDU including a CLOSE 
mark, addressed to the channel which had issued the previous NACK mark. 



2.5 Application Interface 

Smart card applications work with the communication stack through a software 
interface, according to well known open/connect read/recv write/send 
close/shutdown paradigm, used in UNIX systems to manipulate files or TCP/IP sock- 
ets. 
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TSS IS07816 CSS 



Terminal Smart Stack T=x Card Smart Stack 




NETWORK TERMINAL SERIAL LINK SMART CARD 



Fig. 3. Smartcard communication stack 



3 HTTP Server 

An HTTP client sends a request to the server in the form of a request method, URI 
(Unified Resource Identifier - typically a file name and its path), followed by a 
Mime-like message containing requests modifiers, client information and a possible 
body. 

An HTTP daemon processes an incoming message, checks its validity and extracts 
the following basic information: 

• The request method, typically GET or POST. 

• The associated URI. 

• An optional body content. 

When a complete HTTP request has been received, associated parameter are 
passed to the script parser, which then is in charge of the current session manage- 
ment over channel zero. 



4 File System Interface 

Basically smartcard file is a memory (E2PROM) block, characterized by a base ad- 
dress a length and a maximum size (for writing operations). The file system inter- 
face (ESI) associates a name to this object (a file is a named memory area), manages 
its attributes and supervises all access procedures. 

This module performs all operations which are necessary for adapting an 7816 file 
system in order to support an UNIX like naming scheme; although it should be no- 
ticed that sophisticated file system can be implemented in Java language. ESI man- 
ages authentication processes that are compatible with HTTP protocol. It is invoked. 
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• From an HTTP message, incorporating a request method, an URI and an optional 
body content. If a file is protected by an authentication procedure, FSI typically 
generates an HTML page including a form, in order to get all elements needed by 
authentication process (for example login and password). 

• From an XML script, in order to read or modify a smartcard file. If a script at- 
tempts to perform a forbidden file operation, FSI internally produces an error 
message, and script execution is aborted. 

In our full Java FSI implementation, files are identified by a name (up to 255 
characters) and are located in logical partitions, protected by passwords. A file may 
support reading and/or writing operation; it is either public or protected according to 
its partition lock value; an optional HTTP header specifies file MIME type (for ex- 
ample text image or applet). There are two types of files, static files or scripts, which 
are similar to executable files. 




Fig. 4. File System 



5 XML Script Parser 

Script parser is the key point of our experimental smartcard. Once an incoming 
HTTP request has been checked by the web server, all further card operations are 
supervised by this software component. 



5.1 Motivation 

There are two main motivations for organizing an internet smartcard around a cen- 
tral XML parser. 
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• First reason is flexibility, XML script offers a high level description of services 
which are offered by smartcards. Embedded resources are described by specific 
DTD, what guaranties that well formed scripts can be correctly executed. 

• Second reason is supporting an open object distributed architecture. Embedded 
object messages are expressed in XML syntax, which is independent from any 
smartcard operating system. 



5.2 Implementation 

This module managed an HTTP session over channel #0, and an optional second 
channel (#1), created from a script instruction (<Open_l/>. At any time, if HTTP 
session is closed script execution is aborted, and smartcard control is passed back to 
the web server which is then ready for processing next HTTP session. 

A script is a set of smartcard high level instructions which control communication 
sessions and have access to all internal resources, including cryptographic functions 
and client protocols. Thanks to XML syntax, these instructions are described by a 
data type document (DTD) [11,12]. 

A smartcard instruction is associated to an XML empty element <TAG.../>, 
which is made of two parts, a mnemonic and an integer (the instruction number). 

Optional parameters are specified by attributes values, a prefix indicates the at- 
tribute type, i for integer, s for string and f for file; upper case (I,S,F) mean that 
attributes values (i,s,f) are imported from HTML form input fields. 

A script is identified by a file name, and within this file each instruction is assoc i- 
ated to an index, ranging between one (first instruction) and the number of script 
instructions. 

We shall classify instructions in four groups (table 1): 

• Communication instructions, which control data exchange over channels (#0 or 
#1), like open (creating a new communication channel), close (closing a commu- 
nication channel), send (data transmission over a communication channel), recv. 
(data reception over a communication channel). Data reception is always associ- 
ated to a reception protocol (Ptcol), like 

- Raw reception (#0), data are received until channel closing 

- ASNl protocol (#1), incoming data block is encoding according to Abstract 
Syntax Notation 1 . 

- HTTP protocol (#2). 

• Control instructions, which allow script programming, like call, jump , if. 

• Files instructions, which control files operations, like copy (adding data to file) or 
cat (appending data to file). 

• Resources instructions, which access to all available card resources (functions, 
network protocols . . .), like add (adding an integer to a file content). 
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Table 1. Example of XML script instructions 



Instruction 


Description 


Attributes 


Example 






ist 


2nd 




Send_0 


Sending data over a 
channel iCh 


sf 




<Send_0 f=”file” iCh=’T’7> 
<Send_0 s=”Hello” iCh=”0’V> 


Open_l 


Open channel#! and con- 
nect it to an internet server 


sf 




<Open_l s=”host:80’V> 
<Open_l S=”Hosf’> 


Close_2 


Close channel #1 






<Close_2/> 


Recv_3 


Data reception over ch#l 
according to iPtcol 


f 




<Recv_3 f=”file” iPtcol=”0’V> 
<Recv_3 f=”file” iPtcol=”2”/> 


Copy_l 1 


Copy data in a destina- 
tion file fD 


sf 


f 


<Copy_ll s=”Hello” fD=”file’V> 
<Copy_ll f=” source” fD=”DesfV> 


Cat_12 


Append data to a desti- 
nation file fD 


sf 


f 


<Copy_12 s=”Hello” fD=”file”/> 
<Copy_12 f=”source” fD=”dest”/> 


Add_20 


Source-i-Destination => 
Destination 


if 


f 


<Add_20 i=’T000” fD=“balance’7> 
<Add_20 f=”x” fD=”balance’7> 


Call_7 


Call a script 


s 




<Call_7 s=”pme’7> 


Jmp_8 


Jump to a script instruc- 
tion 






<Jump_8 i=”5’7> 


If_9 


If a file content is >= 
jump to an instruction 


f 


i 


<if_9 f=”balance” i=”5”> 



5.3 Executing a script 

Let’s consider a simple script named pme which adds an integer value to a file vari- 
able named Balance. This script uses an input parameter Money which is imported 
from an html form input field. Following the addition procedure, an html page is 
dynamically built in order to display the result. This page is sent over the communi- 
cation channel #0. 



<pme> 

<Add_20 I=”Money” fD=”Balance7> 
<Send_0 f=”Header” iCh=”07> 
<Send_0 f=”Balance” iCh=”07> 
<Send_0 f=’Trailer” iCh=”07> 
</pme> 



Fig. 5. A pme script 
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This script is executed from an HTTP request using either GET method, 
http://127.0.0.1:8080/pme?Money=-\-1000, or POST method produced by an HTML 
form (figure 6). 

<htmlxbody><H 1 >PME</H 1 > 

<EORM METHOD=POST ACTION=/pme> 

<INPUT VALUE=ADD TYPE=submit> 

<INPUT NAME=Money> 

</EORMx/bod 3 C></html> 

Fig. 6. Invoking a smartcard script (pme)from an HTML form 



PME 



ADD llOOO 



5.4 Sending a Message to a Smartcard XML Script 

An XML script can be sent to smartcard in order to be internally processed, in this 
case it acts as an XML encoded message which interacts with smartcard objects. 

<Add_20 f=”In” fD=”Balance7> 

<Copy_ll f=”Balance” fD=”Out'7> 

Fig. 7. Modified pme script. 

For example we can slightly modify our pme script, so that an input (file) variable 
In is added to the balance content; operation result is copied in a file named Out 
(Figure 7). The next step is to send, encapsulated in an URL, an XML script identi- 
fied by the prefix X?x, 

http://127.0.0.1:8080/X?x=<Copy_ll s=”-rl000” fD=’Tn”/> 

<Call_7 s=”pme”/xSend_0 f=”Out” iCh=”0”/> 

This message invokes the pme script with the In value set to -I-IOOO and transmits 
the return value over channel #0. 



5.5 Modeling Network Interaction 

Script may interact with remote internet servers, like for example a LDAP server 
(ils.microsoft.com:389). First step is the creation of a new session over channel #1, 
<Open_ 1 s=”ils . micr osoft . com : 3 8 9”/> 

Upon success, a request message, stored in a file {Out) is sent to remote node, 
<Send_0 f=”Out” iCh=’T”/> 

Script then waits for an incoming response, of which length is determined ac- 
cording to a known protocol, like ASNl for LDAP messages, 

<Recv_3 f=’Tn” iPtcol=’T”> 

An interaction with a remote server consists of one or several message exchanges, 
which are eventually processed by additional script instructions. Script ends a con- 
nection by executing the <Close_2/> instruction. 
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6 JavaCard Implementation 



6.1 Architecture 



abstract class 
Stack extends Applet 



Public boolean 

StackProcess(byte apdu[ ], short len) 



public void DataProcess() 



final class 

FSI 



public static short 
GetFileAdr(byte[ ] name, short 
offset, short length) 



abstract class 
HttpServer extends Stack 



class SmartParser 

extends HttpServer 



public boolean 

— ►ScriptProcess(boolean init) 



"public void process(APDU apdu) 



Fig. 8. JavaCard Software Architecture 

Our software architecture (figure 8) is made up four Java classes. An abstract class 
named Stack implements the SmartTP protocol, all incoming APDUs are processed 
by the StackProcess method. 

Data which are received from logical channels are forwarding, by invoking 
method DataProcess() to an abstract class HTTPServer. HTTP method type (Get or 
Post), URI and optional body content are extracted from an incoming HTTP request. 
When a complete message has been received and checked, all further incoming in- 
formation are transmitted via ScriptProcess() method toward the SmartParser class. 

SmartParser is in charge to analyze the incoming URI, it uses FSI services (in 
particular GetFileAdr method) to determine if a valid file (an E2PROM block) is 
associated to this URI. If the requested file is an XML script, its content is inter- 
preted on a per instruction basis. 
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The code size may be as small as 6.5 Kb (in bytes code units), but obviously it is 
proportional to the number of supported script instructions and is dependent of FSI 
complexity (in term of security features for examples). 



6.2 Performances 



Action 


Time 

ms 


Comments. 


TCP session opening 


110 


An http session is opened 
with smartcard 


HTTP header reception and 


710 


HTTP Header is less than 


processing 




100 bytes 


<Copy_ll f=”G" fD=”Out'7> 




HTTP request building 
G=”GET r 


<Cat_12 S="N" fD="Out"/> 




HTTP request building 
N=”hello.html” 


<Cat_12 f=”E'' fD=”Out'7> 




HTTP request building 
E=”HTTP/1.1 cr Ifcr If’ 


<Open_l S="H7> 


1370 


A connection is opened with 
a remote server H 
(H=host.com) 


<Send_0 f=”Out" iCh='T7> 


660 


HTTP header transmission 


<Recv_3 f='Tn” iPtcol="0'7> 


390 


Data reception from the 
server 


<Send_0 f='Tn” iCh=”0'7> 


220 


Data transmission toward 
browser 



Table 2. Performances example 

Table 2 shows timing measurements observed at script execution which includes 
seven instructions. This test script has two input parameters H (for host name) and N 
(for page name); its function is to open an HTTP session with a remote host (H), and 
then to transmit information, stored in In file back to the browser. The HTTP request 
is built in the Out file, and script is launched from the following URL, 
http://127.0.0. 1 :8080/g?H=host.com&N=hello.html. 



7 Future Work 

We planned to investigate security aspects, for example by supporting additional 
features like script signature and user authentication. 
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8 Conclusion 

We have realized an experimental internet smartcard which is fully programmed by 
XML scripts. Code size and executing times show that this approach is realistic even 
with today existing 8 bits JavaCard. Although we think that security requirements 
need further studies, we believe that this innovative architecture will facilitate smart- 
card integration in internet applications, in which electronic documents use XML 
syntax. 
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Abstract. Contact-less smart cards are very convenient in use and are 
expected to expand the application fields of electronic money; they will 
accelerate the penetration of all electronic money services. Contact-less 
smart cards have limited capabilities and so it is difficult for them to 
perform complicated operations such as public key cryptographic 
processing. Moreover, the usage style of contact-less smart cards makes 
it difficult to guarantee the consistency of the transaction. To answer 
these questions, we have developed a high-speed payment processing 
system. Based on the elliptic curve digital signature algorithm, the 
proposed system reduces the processing time and the amount of data 
that needs to be transmitted. We describe a typical implementation that 
uses pre-computation. Also described here is a transaction mechanism 
that ensures processing consistency in the face of the unstable operating 
environment of contact-less smart cards. 



1 Introduction 

Smart cards are becoming extremely popular; over 800,000,000 units were shipped in 
the fiscal year of 2000 [1]. Its application fields are expanding from communication 
and finance, to public transportation, electronic authentication, and administration 
services. 

In the finance field, there are already several electronic money schemes offering 
commercial services like MONDEX [2], Geld Karte [3], Proton [4], and Visa Cash 
[5]. In Japan, NTT has been investigating electronic money schemes. We have 
demonstrated our schemes in commercial trials. Internet Cash [9] is the electronic 
money trial service for virtual shops on the Internet, and Super Cash[10] is a large 
scale electronic money trial service; customers can use the electronic money in real 
shops, vending machines, and virtual shops on the Internet. 
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In the public transportation field, such as railroad, subway, and bus companies are 
investigating the introduction of smart cards for ticket gating. The transportation card 
called OCTPUS [6] was put into service in September of 1997 in Hong Kong. About 
7 million OCTPUS cards have been issued, and customers can use them for a wide 
range of transportation services, such as trains, subways, buses, and ferries. In Japan, 
the East Japan Railway Company has decided to introduce the same type of 
transportation card, called SUICA (Super Urban Intelligent CArd) [7], in metropolitan 
Tokyo in 2001. 

These public transportation-gating cards are contact-less because they simplify the 
operations and increase the customer’s convenience. Instead of inserting the card into 
a card reader/writer; customers can pass through the gates simply by waving the cards 
close to the reader/writer, even if the card remains in a wallet. 

Most of the electronic money schemes, including NTT’s electronic money, are 
built on public key cryptographic systems and use contact-type smart cards for their 
certainty and safety. Electronic money schemes may offer conventional cash features, 
such as user anonymity, person-to-person transferability, but the most important 
features are the certainty of the payment process and the prevention of malicious use. 
The financial institutions that have been investigating the contact-type smart cards 
have demanded the high security traditionally only possible with public key 
cryptographic systems. It has been assumed that security far outweighed processing 
speed. 

From the customer’s point of view, however, the use of contact-less smart cards 
sounds very attractive. The trick is to be able to offer the same security and 
functionality as regular contact-type smart cards. 

This paper introduces a high-speed electronic money payment system that uses contact-less 
smart cards; it offers excellent security and reliability based on a public key cryptographic 
system. Its performance is certainly practical, a complete payment cycle can be completed 
within 0.4 seconds. 



2 Application of the Contact-Less Smart Card 
of Electronic Money 

2.1 Electronic Money Scheme 

In electronic money schemes, money is stored as electronic value in the smart cards. 
This electronic value should be transferred when making a payment such as paying a 
conventional bill. 

Various electronic money schemes or services has been proposed and introduced, 
and they have features such as virtual shop/real shop support, smart card (off-line) 
type/server-access type, open-loop circulation type/closed-loop circulation type, 
etc [13]. 

NTT’s electronic money scheme has the following features. 

- Payment scheme for real shops: The ability to use electronic money at real shops, 
such as kiosks and convenience stores is the key to popularizing electronic money. 
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- Smart card based: Smart cards are tamper-resistant devices, and offer high 
security and high convenience. 

Issuer 



f- P m cM 

' a&FP 



Return Bank B 

^ r-1 




Shop 



Fig. 1. Basic scheme of NTT’s electronic money system 



- Payment can be accomplished without accessing the server systems: NTT’s 
electronic money scheme allows the user to use off-line electronic money payment, 
and the shop to store electronic money data in a non-tamper-resistant storage 
device such as a database. 

- High security and reliability: NTT’s electronic money scheme uses electronic 
signatures to prevent illegal usage such as eavesdropping, overspending, 
counterfeiting, copying, and alteration. 

2.2 Contact-Less Smart Cards 

Application using contact-less smart cards have been advanced focusing on the field, 
which needs rapid processing, such as payment at the fare gate. 

Contact-less smart cards remove the need to insert the card into the reader/writer in 
using; the user simply waves the card close to the reader/writer, the card can even be 
kept in his wallet. In addition, since no physical contact is needed, maintenance of the 
reader/writer is easy and durability is high. 

The contact-less smart card is excellent not only in terms of user-friendliness but 
also technically. For example, a communication speed between smart card and 
reader/writer is improved as compared with a contact smart card. The basic 
communication speed of a contact smart card, based on IS07816 [14], is 9600bps. 
That of a contact-less smart card, based on ISO 14443 [15], is 106Kbps, and two 
communication signal interfaces, Type-A and Type-B, are standardized. 
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3 Problems in Implementing Contact-Less Smart Card 

To expand the use field of contact-less smart cards, we must prepare the certainty of 
the payment process and prevent illegal usages, such as eavesdropping, overspending, 
counterfeiting, copying, and alteration; for this purpose we adopt electronic 
signatures. 

In order to realize a contact-less smart card that offers secure and high speed 
electronic payments, it is necessary to solve the following problems. 



3.1 The Problem of Processing Time 

The use of a contact-type smart card requires it to be inserted into a reader/writer. 
Since the mechanical functions of insertion and ejection take time, processing time 
did not have to be fast. 

The purpose of the contact-less smart card is to improve user convenience so speed 
I critical. The contact-less smart card can operate only in a magnetic field that emitted 
from reader/writer. Considering that the user will wave the card over the 
reader/writer, the process must be completed while the card moves a magnetic field; 
the processing time must be less than 1 second. This leads to the second problem. 

3.1.1 The Problem of Communication Time 

In order to accelerate payment processing by taking full advantage of the high 
communication speeds of contact-less smart cards, it is important to reduce the size of 
data transmitted and to reduce the need for block chaining. 

By adopting a contact-less smart card, the communication speed between the card 
and the terminal improves. In general, however, the communication buffer of a 
contact-less smart card is small compared to that of a contact-type smart card. Data 
that exceeds communication buffer size is transmitted in several step^ We call such 
data transmission block chaining. 

In electronic money systems based on public-key cryptography, it is necessary to 
transmit a lot of data, such as signatures and certificates. It is important to reduce the 
size of data transmitted and to reduce the need for block chaining. 

3.1.2 The Problem of Signature Generation Time 

In our electronic money system, ESIGN [16] and RSA [17] were adopted as public- 
key cryptographic systems. In order for a smart card to create the signatures like RSA, 
it must use a specialized cryptographic co-processor. It is difficult for contact-less 
smart cards to use such co-processors because their power consumption is high. 
Current chip technology makes it difficult for a contact-less smart card to supply 
enough electronic power to the co-processor; the power is supplied from the 
reader/writer by microwave transmission. 

For example, in the case of RSA, the key length is usually 1024 bits. In that case, 
we need to perform 1024 bit-long integer calculations. This demands a co-processor 



^ This is the feature of the T=1 protoeol. 
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with high clock speeds, 5MHz or more [10]. It is clear that we need a way of 
shortening the signature generation time without requiring the use of a co-processor. 

3.2 The Problem of Guaranteeing Payment Completion 
and Data Consistency 

Our existing electronic money system completes the transfer of electronic money by 
passing messages between the card and the read/writer. The failures of the 
communication path between the two of them during a transaction can serious impact 
the integrity of the card’s contents. 

A smart card, which has a CPU, is a kind of microcomputer. Unlike a regular 
microcomputer, a smart card does not contain its own power source. Inadvertent or 
malicious power interruptions can cause destruction of the stored data structure. 
Therefore, problems that arise when updating of the data may cause the loss of 
electronic money. 

Our existing electronic money system uses various management techniques to 
support practical use [9]. For example, in order to prevent the loss of electronic 
money, the card itself is mounted in the reader/writer in such a way so as to prevent 
power interruptions and transmission errors. 

The user of a contact-less smart card can move freely with the smart card. 
Therefore, the occurrence of transmission errors and power interruptions are greatly 
increased. 

It is necessary to enhance the management software on the system side to cope 
with this problem. 



4 Implementation Methods for Realizing the Security of Contact- 
Less Smart Cards 

We adopted the following approaches to achieve adequate security and payment 
speed in contact-less smart card system. 

4.1 Elliptic Curve DSA 

We selected the ECDSA (Elliptic Curve Digital Signature Algorithm) for signature 
generation. The elliptic curve DSA has the following merits. 

4.1.1 Less Data is Transmitted: 

The ECC (Elliptic Curve Cryptosystem^] provides the highest strength-per-bit of any 
cryptosystem known today. This means that smaller key sizes yield equivalent levels 
of security. To achieve reasonable security, RSA should employ 1024-bit modulus, 
while a 160-bit modulus should be sufficient for ECC [18]. The smaller key size 
means that signatures and certificates are smaller. Less data needs to be transmitted 
between the card and the terminal so communication times are shorter. 



^ ECDSA is the elliptic curve analogue of DSA 
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4.1.2 Performance: 

ECC, in which is selected as the underlying finite field, can be implemented 

very efficiently, and offers high performance on smart cards [19] [20] [21]. Most of the 
computation for ECC takes place at the finite field level, and the algorithm can be 
implemented in available ROM, so no co-processor is required to perform signature 
generation!] 

4.2 Pre-computation to Shorten Signature Generation Time 

The Elliptic Curve Digital Signature Algorithm (ECDSA) and ESIGN algorithms can 
be divided into two parts: the message independent portion and the message 
dependent portion. By using this division, we can greatly shorten the signature 
generation time [26]. 

The signature generation algorithm of ECDSA is as follows. 



Generate random number k (1) 

R = (R^,R^) = kP (2) 

r = R^modn (^) 

s = k~^ (h(m) + xr) mod n 



Where P(P^^Py) is the base point, n is the base point order, X is the 

private key, r is the first signature parameter, s is the second signature 
parameter, and m is the message. 

In the above algorithm, steps (1), (2), (3), and the following step can be done at any 
time and are independent of the message begin signed. Thus, in advance of signature 
generation, the set of values (r, kl^ xP) can be calculated. 



kl — k ' modn 


(5) 


xr'- xrmodn 


(6) 



At the time of signature generation, we simply calculate for the remaining values 
as shown below. 



^ The contact-less smart card, which has DES and T-DES accelerator, can perform ECC more 
high speed because the addition operation over a filed r can be perform by XOR 
operation. 
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Generate hash value h{m) C^) 

s = k\{h{m) + xr ’ ) mod n (8) 

We used this technique, whereby the message independent portion is processed 
beforehand and the results (r, A:l,xr’) are stored in the smart card’s non-volatile 
memory area. The remaining portion (steps (7) and (8)) is processed at the time of 
signature generation, whereupon both results are combined. This technique 
dramatically reduces signature generation time. 

4.3 Introduction of Efficient Resending and Transaction Mechanism 

Our existing electric money system uses a re-sending mechanism in case for the 
transmission failures. This mechanism, stores the data needed to reconstruct the 
response to the terminal, such as payment challenge data, in non-volatile memory 
before transmission. When the smart card receives the payment request that has same 
payment challenge data as previous request, it reconstructs the response using stored 
data, and resends the response. 

Furthermore, in order to guarantee the consistency of the data updated by the whole 
smart card, we implemented a transaction management mechanism. The smart card 
maintains a commit buffer in non-volatile memory that stores the original contents of 
updated data until the transaction is finished. Should a transaction fail before 
completion, the data associated with the transaction are restored to their original 
values held in the commit buffer. 

The problems of the mechanism described above include too many write 
operations to non-volatile memory and the overhead of managing data updates. 

In order to reduce these processing times, we adopt a method that guarantees the 
completion of the entire electronic money payment process and the consistency of 
data while requiring fewer writes to non-volatile memory. 

First, in order to avoid the overhead associated with managing data updating, all 
data to be updated (include the data required to reconstruct the response to the 
terminal) is unified and managed in one area (we call this area the log). This removes 
the need manage different data update operations separately, only the updating state 
of the log. 

To update the log atomically, we need two non-volatile memory areas that store the 
latest log and previous log. When we update the log, the latest log is copied to volatile 
memory, and each set of data log is updated appropriately on volatile memory. When 
updating (transaction) is completed, the log on the volatile memory area is copied to 
the previous log. 

This transaction mechanism protects against such events as power loss in the 
middle of a transaction because no change is made to the latest log. 

This mechanism is suitable for smart card implementation. Most smart cards use 
EEPROM for non-volatile memory, and RAM is used for volatile memory. EEPROM 
has a write-access time of about 7 milliseconds which is approximately 10,000 times 
slower than RAM [25]. Accordingly, reducing the number of writes that need to be 
made to EEPROM is very effective in minimizing the processing time. 
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5 Implementation and Results 

We implemented an electronic money application using a commercial smart card and 
the techniques described in this paper. 



5.1 Experiment Overview 

The experimental environment is detailed in Table 1 and the electronic money 
payment sequence is shown in Fig. 2. The smart card used in this implementation, is a 
commercially available smart card that supports the both interface: contact and 

contact-less (Type-B interface). With ECDSA, is selected as the underlying 

finite field. SHA-1 is adopted as the hash function. To authenticate the terminal, we 
use Triple-DES. 



Table 1. Experiment environment 



Smart Card 


CPU 


16bit (eore 8bit), 3.39MHz 


RAM 


1.2KB 


EEPROM 


16KB 


Interfaee 


Dual Interfaee (eontaet/eontaet-less) 


Contaet-less Smart Card Reader/Writer 


To Smart Card 106Kbps (Type-B eontaet-less) 


To Terminal 


115Kbps(RS-232C) 


PC terminal 


CPU 


Pentiumlll 800MHz 


RAM 


256MB 


OS 


Windows98 



PC Terminal Reader/Writer Smart Card 




Fig. 2. Sequenee of eleetronie money payment 
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5.2 Results 

In our implementation, the complete payment processing time is about 0.4 seconds. 
This time covers creating the payment challenge on the PC, command sequence in 
Fig. 2, and payment verification on the PC. 

Table 2 and Fig. 3 compare the processing time for the electronic money payment 
portion as realized by RSA and ECDSA, and between the contact and contact-less 
modes. The performance of RSA is an estimated value assuming that the 
communication speed is 9600bps(contact) and 106Kbps(contact-less), and the 
signature generation performance (RSA 1024bit with CRT) is referred for the 
technical newsletter of RSA laboratories [17]. 

Fig. 3 shows that the performance of our contact-less smart card offer excellent 
performance, better than that of a smart card with an RSA co-processor and contact- 
less interface. 



Table 2. Performance comparison of signature algorithms and interfaces 





Transmission time 


Execution time 


ECDSA 163bit+ Pre-computation 
Contact-less I/F 


23ms 


138ms 


RSA(CRT) 1024bit Contact-less I/F 


40ms 


330ms 


RSA(CRT) 1024bit Contact I/F 


503ms 


330ms 
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Fig. 3. Performance comparison of signature algorithm and interfaces 



5.2.1 The Effect by Reducing the Amount of Transmitted Data 

In our electronic money system, the smart card returns the signature and user public- 
key certificate as its response. 
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We estimated the block chaining number and transmission time, the results are 
shown in Table 3. This estimation assumes that the size of the communication buffer 
is 254 Bytes (contact) and 127 Bytes (contact-less). 

Table 3 confirms that the block chaining number is reduced the smaller volume of 
transmitted data. This minimizes the transmission time. 



Table 3. Comparison of transmission time 





Size of response 


Block chaining 


Transmission time 


RSA(with CRT) 1024bit 
Contact I/F 


310 Bytes 


2 


503ms 


RSA(with CRT) 1024bit 
Contact-less I/F 


3 


40ms 


ECDSA 160bit 
Contact-less I/F 


141 Bytes 


2 


23ms 



5.2.2 The Effect of Pre-computation 

The impact of the pre-computation technique on signature generation performance is 
shown Table 4. 

In our implementation, the signature generation process involves just one addition 
and one multiplication. As a result, the signature generation time is shortened by 93%. 

When we use the pre-computation technique, the pre-computed values must be 
erased after each payment to prevent disclosure of the private key. In our 
implementation, the pre-computed values are computed and stored during the 
electronic money loading. 



Table 4. The effect of pre-computation 





With pre-computation 


Without pre-computation 


Signature 
generation time 


38 ms 


522 ms 



5.2.3 Evaluation of Transaction Mechanism 

We prepared four log areas in EEPROM a nd a pointer that indicates the latest log to 
implement the method described in section EU 

When we refer to the balance in the smart card, we refer to the data in the log 
indicated by the pointer. In same way, the data required to reconstruct the response to 
the terminal is found from the indicated log. In our implementation, eight values must 
be update during payment transaction. The total size of this data can be stored in one 
page (64byte/page). Our conventional transaction mechanism needs 16 EEPROM 
writes (to store each values to the commit buffer, and update each value) per 
transaction. In this implementation, only two EEPROM writes (see Fig. 4) were 
needed per transaction. Assuming that an EEPROM page-write-access time of 7 
milliseconds, processing is shortened from 1 12ms to 14ms. 
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COPY 




EEPROM RAM 




STEP2: Up date payment log 




STEPS: Finish transaction 




Fig. 4. Transaction mechanism 



6 Conclusion 

We have realized a high-speed payment system that uses contact-less smart cards. 
The system can complete an electronic money payment within 0.4 seconds. It will 
expand the popularity of electronic money systems because it offers the very high- 
speed processing needed in applications such as public transportation and shop 
registers. 

To confirm the system’s feasibility, we implemented it on a dual interface smart 
card, which means that conventional smart card reader/writers can also be used. 
Although contact-less smart card reader/writers are currently expensive, their price is 
expected to fall. Contact smart card reader/writers will probably remain cheaper and 
so will be used in the home. For example, electronic money loading could be done at 
home using the contact interface, while payments at shop counters could be done 
using the contact-less interface. 

The system's high-speed signature generation technique and high-speed transaction 
mechanism are not restricted to electronic money payment; they can be applied to 
other smart card applications. We are going to apply this technology to other 
applications that need the security offered by public-key cryptography, such as 
electronic tickets and personal forms of identification. 
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